Did you see the background section? I meant that to provide that information. I was unclear on how much to assume the audience already knows about the subject.
Hal > -----Original Message----- > From: Henry Saputra [mailto:henry.sapu...@gmail.com] > Sent: Thursday, November 13, 2014 4:31 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Could you add more description on what is PEP and PDP and other > acronyms used in the proposal? If it is not directly relevant maybe you > can rephrase it to more generic analogy. > > Thanks, > > Henry > > On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart <hal.lockh...@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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
