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/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 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
