Hi! can you please fix the formatting issues? For example, I can't even tell the exact list of mentors you're proposing.
Thanks, Roman. On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <hal.lockh...@oracle.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
