Ah my bad, I usually use abstract section to get main idea of the proposal.
And as per John request, lets start with DISCUSS thread instead. - Henry On Thu, Nov 13, 2014 at 2:59 PM, Hal Lockhart <hal.lockh...@oracle.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
