incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <john.d.am...@gmail.com>
Subject Re: [PROPOSAL] OpenAZ as new Incubator project
Date Fri, 14 Nov 2014 01:59:15 GMT
I think so.

There's a few things that you want to iron out first, before people start
voting on this.

- 3 is generally the "minimum" number of mentors.
- I can't find a "Paul Freemantle" on the apache committers list.  There's
a Paul Fremantle, minor spelling difference.
- You may want to review this section to get a better understanding of the
goals: http://incubator.apache.org/guides/proposal.html#formulating

the Discuss option just helps everyone look at your proposal a little bit
better and determine if there's any gotchas.  For example, I'm surprised to
see a new incubator project using SVN.

- Can you list out your issue tracking preference (should probably be JIRA
unless you need something else)
- Please also explicitly list the mailing lists your want.

John

On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart <hal.lockhart@oracle.com>
wrote:

> So you want me to repost the proposal with the Subject changed to start
> with "[DISCUSS]"? Or should I simply reference the wiki page?
>
> Hal
>
> > -----Original Message-----
> > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > Sent: Thursday, November 13, 2014 5:03 PM
> > To: general@incubator.apache.org
> > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> >
> > Hal,
> >
> > Per customs, would you mind if we cancel this and start with a
> > [DISCUSS] thread about OpenAZ?  It's unclear if you meant this to be a
> > vote or something.
> >
> > John
> >
> > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <hal.lockhart@oracle.com>
> > wrote:
> >
> > > Abstract
> > >
> > > OpenAz is a project to create tools and libraries to enable the
> > > development of Attribute-based Access Control (ABAC) Systems in a
> > > variety of languages. In general the work is at least consistent with
> > > or actually conformant to the OASIS XACML Standard.
> > >
> > > Proposal
> > >
> > > Generally the work falls into two categories: ready to use tools
> > which
> > > implement standardized or well understood components of an ABAC
> > system
> > > and design proposals and proof of concept code relating to less well
> > > understood or experimental aspects of the problem.
> > >
> > > Much of the work to date has revolved around defining interfaces
> > > enabling a PEP to request an access control decision from a PDP. The
> > > XACML standard defines an abstract request format in xml and protocol
> > > wire formats in xaml and json, but it does not specify programmatic
> > interfaces in any language.
> > > The standard says that the use of XML (or JSON) is not required only
> > > the semantics equivalent.
> > >
> > > The first Interface, AzAPI is modeled closely on the XACML defined
> > > interface, expressed in Java. One of the goals was to support calls
> > to
> > > both a PDP local to the same process and a PDP in a remote server.
> > > AzAPI includes the interface, reference code to handle things like
> > the
> > > many supported datatypes in XACML and glue code to mate it to the
> > open
> > > source Sun XACML implementation.
> > >
> > > Because of the dependence on Sun XACML (which is XACML 2.0) the
> > > interface was missing some XACML 3.0 features. More recently this was
> > > corrected and
> > > WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the
> > > JPMC team to support calling a remote PDP. WSo2 is also pursuing this
> > capability.
> > >
> > > A second, higher level interface, PEPAPI was also defined. PEPAPI is
> > > more intended for application developers with little knowledge of
> > > XACML. It allows Java objects which contain attribute information to
> > be passed in.
> > > Conversion methods, called mappers extract information from the
> > > objects and present it in the format expected by XACML. Some
> > > implementers have chosen to implement PEPAPI directly against their
> > PDP, omitting the use of AzAPI.
> > > Naomaru Itoi defined a C++ interface which closely matches the Java
> > one.
> > >
> > > Examples of more speculative work include: proposals for registration
> > > and dispatch of Obligation and Advice handlers, a scheme called AMF
> > to
> > > tell PIPs how to retrieve attributes and PIP code to implement it,
> > > discussion of PoC code to demonstrate the use of XACML policies to
> > > drive OAuth interations and a proposal to use XACML policies to
> > express OAuth scope.
> > >
> > > AT&T has recently contributed their extensive XACML framework to the
> > > project.
> > >
> > > The AT&T framework represents the entire XACML 3.0 object set as a
> > > collection of Java interfaces and standard implementations of those
> > > interfaces.  The AT&T PDP engine is built on top of this framework
> > and
> > > represents a complete implementation of a XACML 3.0 PDP, including
> > all
> > > of the multi-decision profiles. In addition, the framework also
> > > contains an implementation of the OASIS XACML 3.0 RESTful API v1.0
> > and
> > > XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> > > functionality, allowing application developers to simply annotate a
> > > Java class to provide attributes for a request. The annotation
> > support
> > > removes the need for application developers to learn much of the API.
> > >
> > > The AT&T framework also includes interfaces and implementations to
> > > standardize development of PIP engines that are used by the AT&T PDP
> > > implementation, and can be used by other implementations built on top
> > > of the AT&T framework. The framework also includes interfaces and
> > > implementations for a PAP distributed cloud infrastructure of PDP
> > > nodes that includes support for policy distribution and pip
> > > configurations. This PAP infrastructure includes a web application
> > > administrative console that contains a XACML 3.0 policy editor,
> > > attribute dictionary support, and management of PDP RESTful node
> > > instances. In addition, there are tools available for policy
> > simulation.
> > >
> > > Background
> > >
> > > Access Control is in some ways the most basic IT Security service. It
> > > consists of making a decision about whether a particular request
> > > should be allowed and enforcing that decision. Aside from schemes
> > like
> > > permission bits and Access Control Lists (ACLs) the most common way
> > > access control is implemented is as code in a server or application
> > > which typically intertwines access control logic with business logic,
> > > User interface and other software. This makes it difficult to
> > > understand, modify, analyze or even locate the security policy. The
> > > primary challenge of Access Control is striking the right balance
> > > between powerful expression and intelligibility to human beings.
> > >
> > > The OASIS XACML Standard exemplifies Attribute-Based Access Control
> > > (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from
> > > other components. The Policy Enforcement Point (PEP) must be located
> > > so as to be able to enforce the decision, typically near the
> > resource.
> > > The PEP first asks the PDP if access should be allowed and provides
> > > data, in the form of Attributes, to be used as input to the policies
> > held by the PDP.
> > >
> > > In addition to responding permit or deny, XACML allows a policy to
> > > emit Obligations or Advice, which direct the PEP to do certain
> > things,
> > > such logging the access or failure or promising to get rid of the
> > data
> > > after 30 days.
> > >
> > > Attributes are identified as being in a certain category which
> > > represents one element in the proposed access. For example attributes
> > > may be associated with the resource being accessed, the action being
> > > taken or the environment, .e.g. date/time. Attributes may also be
> > > associated with any or several types of Subjects, which represent the
> > > active parties to the access, such as the requester, intermediaries,
> > > the recipient (if different), the codebase, the machine executing the
> > code.
> > >
> > > Attributes may be provided by the PEP and usually at least a few are,
> > > but Attributes may also added by other components of the system. It
> > is
> > > also possible for a PDP to add attributes in the middle of policy
> > evaluation.
> > > All of these obtain Attributes from the Policy Information Point
> > (PIP).
> > >
> > > The Policy Administration Point (PAP) creates policies and manages
> > > then through their life cycles and generally the entire
> > infrastructure.
> > >
> > > The XACML language is essentially a set of expressions which evaluate
> > > to a Boolean. If true the policy is said to be applicable. The Policy
> > > contains permit or deny and may include Permissions and or Advice. If
> > > policies disagree we resolve the conflict with combining algorithms.
> > > XACML provides some standard ones and you can implement your own.
> > > Mostly they are common sense like drop non-applicable polices. A
> > > commonly used algorithm is default deny. Deny overrides permit.
> > >
> > > Rationale
> > >
> > > Access Control may be the most basic security service, but for the
> > > most part it remains primitive in practice. While other services like
> > > message protection and authentication have seen many advances in
> > > recent years and decades, deployed access control systems are opaque,
> > > difficult to us and harder to manage. Most organizations claim that
> > > they have security policies, protect privacy and accurately report
> > > financial results, but in practice they have no real way of
> > > discovering whether their systems actually behave the way they are
> > alleged to do.
> > >
> > > Just the foreground problems relating to deploying practical ABAC
> > > systems make a formidable list. If only the PDP knows what the
> > > policies are, how do we make sure it gets the attributes it needs to
> > > evaluate policies? How can we name organize, register and dispatch
> > > Obligations and Advice, allowing handlers to be provided by the
> > system
> > > and added by users? How can the XACML
> > > 3.0 feature of being able to create your own attribute categories
> > best
> > > be supported by the infrastructure and utilized by users? What are
> > the
> > > best ways to create and test policies? What tools will best help us
> > > analyze the effects of the policies in force?
> > >
> > > However, new requirements are rapidly being introduced and need to be
> > met.
> > > Privacy requirements continue to increase in complexity and scope.
> > > Data which moves around, such as documents, need to be protected. We
> > > need secure ways to delegate authority without undermining the
> > > integrity of the access control system. New applications, business
> > and
> > > social relationships are driving the need for new policy and
> > delegation capabilities.
> > >
> > > We believe that the way to meet these challenges is to get more
> > people
> > > actively engaged in using what is currently available so they can
> > > understand its limitations and make it better. We need to make it far
> > > easier to get a basic access control infrastructure up and running.
> > We
> > > need more people who are familiar with XACML the way many people are
> > > familiar with SQL. If as some people say, XACML is the assembly
> > > language of access control, we need the real world experience with it
> > > that will lead us to the useful abstractions that can be implemented
> > > in higher level languages and other tools.
> > >
> > > Initial Goals
> > >
> > > Work is currently underway to extend the PEPAPI and increase its
> > > flexibility. Since it does not directly correspond to any standard
> > the
> > > way AzAPI does, it is necessary to struggle with the issues of what
> > to
> > > expose and what to hide from consumers of the API.
> > >
> > > Other work in progress involves the architecture of Obligations and
> > > Advice. There is also an effort to develop a remote client which can
> > > easily be dropped into any Java environment and make decision
> > requests
> > > of any commercial or open source XACML PDP.
> > >
> > > The contribution of AT&T's framework creates a need to integrate the
> > > prior work with it. Most of the focus will be on AzAPI and the
> > > corresponding AT&T API, which do largely the same thing. The result
> > is
> > > likely to be a synthesis, since each has features the other lacks.
> > > Then PEPAPI will need to be integrated with the new API. The AT&T PDP
> > > and PAP will be incorporated as is. There has been some parallel work
> > > done in the area of PIPs. Work will be required to understand how to
> > proceed here.
> > >
> > > Current Status
> > >
> > >        Meritocracy
> > >
> > > The project was started by Prateek Mishra, Rich Levinson and Hal
> > > Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> > > code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> > > Duanhua Tu and Ajith Nair contributed code both using and extending
> > > AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> > > proposed by Hal Lockhart. In
> > > 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated AzAPI to
> > > include all XACML 3.0 features. In 2014 Pam Dragosh and Chris Rath
> > > contributed the XACML infrastructure they had developed at AT&T.
> > >
> > > During most of its history the project has been very small and has
> > > made decisions by informal consensus. Major design issues have been
> > > decided by open debate. Minor issues and experimental proposals have
> > > been openly welcomed. Several of the participants have a background
> > in
> > > open consensus-based standards making.
> > >
> > > In addition to the mailing list, the project has regular phone calls
> > > every other Thursday.
> > >
> > >        Community
> > >
> > > The original focus of the project was to attract developers of XACML
> > > products, either individuals or corporations, and to build alignment
> > > among vendors on a common API that could simplify technical
> > > integration for their customers.  As OpenAz has matured, our
> > community
> > > has grown to include application developers working to adopt and
> > deploy XACML in their
> > > applications.   So, for example, contributions reflect what
> > individual
> > > developers have learned in vertical industries such as financial
> > > services, healthcare, and computing and communications services, and
> > > our APIs and internal component architecture have evolved to reflect
> > a
> > > strong practical understanding of what it takes to deploy XACML
> > > applications in a large organization.
> > >
> > >        Core Developers
> > >
> > > The following developers have written most of the code to date.
> > >
> > > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> > > rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> > > jpmchase dot com> Chris Rath <car at research dot att dot com>
> > Duanhua
> > > Tu <duanhua.tu at jpmchase dot com>
> > >
> > > The following people made other significant technical contributions.
> > >
> > > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> > > <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> > > oracle dot com>
> > >
> > >
> > >        Alignment
> > >
> > > It has always been a goal to make OpenAz an Apache project. The
> > Apache
> > > license was used for all contributions. We believe the project has
> > now
> > > reached a critical size in terms of developers, organizations and
> > > contributed code to make it appropriate to make a proposal to the
> > Incubator.
> > >
> > > Known Risks
> > >
> > >        Orphaned Projects
> > >
> > > Given the small size of the project, there is a risk of the project
> > > being orphaned. There seems to be strong interest in the use of our
> > > tools, which should markedly increase with the contribution of the
> > > AT&T code. "Where can I get an open source PDP?" and "where can I get
> > > an open source policy editor?" are frequent questions on XACML
> > mailing lists.
> > >
> > >        Inexperience with Open Source
> > >
> > > While few of the developers have extensive experience with open
> > > source, a number of us have long experience in standards making in
> > > open consensus-based environments. For example the XACML TC has
> > > operated since
> > > 2001 based on consensus building, with few, if any votes which were
> > > not unanimous. The main challenge to the project will be managing the
> > > process with more participants and a more formal process.
> > >
> > >        Homogeneous Developers
> > >
> > > Currently all the contributors are employees either of companies
> > > offering an XACML product or large end users deploying XACML
> > > technology for internal use. The positive aspect is that they are all
> > > highly experienced senior developers used to operating in a
> > > disciplined environment. The disadvantage is that the focus to date
> > > has mostly been problems that arise in large scale environments
> > typified by the infrastructure of large corporations.
> > >
> > >        Reliance on Salaried Developers
> > >
> > > All current committers are salaried developers. However the
> > > organizations they work for have a long term commitment to the
> > > technology. We hope that in the Apache foundation we will be able to
> > > attract new developers to help us address the many fascinating
> > > unsolved technological problems associated with deploying ABAC.
> > >
> > >        Relationship with other Apache Projects
> > >
> > > As far as we can determine, no existing Apache project overlaps with
> > > OpenAz in its goals of the technology developed so far. However,
> > > beyond the immediate project goals there are many potential
> > > opportunities for integration with existing Apache projects. Shiro,
> > > Turbine and WSS4J are Java frameworks which could incorporate XACML
> > as
> > > the policy language using OpenAz components. Manifold CF, Qpid and
> > > Archiva already have hooks to incorporate external access control
> > systems.
> > >
> > >
> > >        An Excessive Fascination with the Apache Brand
> > >
> > > We hope that becoming an Apache project will not only attract new
> > > participants to OpenAz, but will draw attention to the neglected
> > field
> > > of access control. As previously stated it has always been our goal
> > to
> > > join Apache, the only question was when the time was ripe.
> > >
> > > Documentation
> > >
> > > The OpenAz web site is:
> > >
> > > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> > >
> > > Java docs can be found here:
> > >
> > >
> > >
> > http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
> > > index.html
> > >
> > >
> > > Initial Source
> > >
> > > The AzAPI, PEPAPI and other related code can be found on sourceforge:
> > >
> > > http://openaz.svn.sourceforge.net/viewvc/openaz/
> > >
> > >
> > > AT&T's framework can be found on github:
> > >
> > > https://github.com/att/XACML
> > >
> > >
> > > Source and Intellectual Property Submission Plan
> > >
> > > TBD
> > >
> > > External Dependencies
> > >
> > > There aren't any we are aware of. The AT&T software is available
> > under
> > > the MIT license, but that seems to be permissible under Apache rules.
> > >
> > > Cryptography
> > >
> > > OpenAz does not provide any cryptographic capabilities. The XACML
> > > Standard does specify some uses of cryptography directly, e.g.
> > digital
> > > signatures over policies and others by implication, e.g.
> > > authentication via cryptography.
> > >
> > > Required Resources
> > >
> > >        Mailing lists
> > >
> > > The standard lists should be sufficient at the current time.
> > >
> > >        Subversion Directory
> > >
> > > We propose: https://svn.apache.org/repos/asf/incubator/openaz
> > >
> > >        Issue Tracking
> > >
> > > TBD
> > >
> > > Initial Committers
> > >
> > > Rich Levinson
> > > Hal Lockhart
> > > Prateek Mishra
> > > David Laurance
> > > Duanhua Tu
> > > Ajith Nair
> > > Srijith Nair
> > > Pam Dragosh
> > > Chris Rath
> > >
> > >
> > > Affiliations
> > >
> > > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> > > Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> > > Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> > >
> > > Sponsors
> > >
> > >        Champion
> > > Paul Freemantle
> > >
> > >        Nominated Mentors
> > > Emmanuel LĂ©charny
> > > Colm MacCárthaigh
> > >
> > >        Sponsoring Entity
> > > The Sponsoring Entity will be the Incubator.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message