[RESULT] [VOTE] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Hal Lockhart <ha...@oracle.com>]

Vote passes with:

[6] +1 (binding): hadrian, coheigea, elecharny, pzf, adc, jani

[6] +1 (non-binding): chris rath, rich levinson, pam dragosh, dilli arumungam, david laurance, hal lockhart

[0] -1:

Congratulations and good luck to the OpenAZ community.

Hal

> -----Original Message-----
> From: Hal Lockhart
> Sent: Monday, January 05, 2015 1:16 PM
> To: general@incubator.apache.org
> Subject: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into
> the Apache Incubator
> 
> I call a vote to accept OpenAz as a new Incubator project.
> 
> The proposal can be found here:
> https://wiki.apache.org/incubator/OpenAZProposal
> 
> and is included below in this email.
> 
> Voting will remain open until at least January 20, 2015 23:00 ET.
> 
> Hal Lockhart
> 
> -----------------------------------------------------------------------
> ----------------
> 
> 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 semantic 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/i
> ndex.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
> 
> All the OpenAz code has been submitted under the Apache 2.0 license.
> The AT&T software is available under the MIT license. Over time the
> project will move to a single license.
> 
> External Dependencies
> 
> There aren't any we are aware of.
> 
> 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.The mailing
> list name will be openaz.
> 
> Git Directory
> 
> We propose: https://git-wip-us.apache.org/repos/asf/incubator-
> openaz.git
> 
> Issue Tracking
> 
> The project will use JIRA for issue tracking.
> 
> 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 Fremantle
> 
> Nominated Mentors
> 
> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> 
> 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