incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: [PROPOSAL] OpenAZ as new Incubator project
Date Thu, 13 Nov 2014 22:02:38 GMT

Per customs, would you mind if we cancel this and start with a [DISCUSS]
thread about OpenAZ?  It's unclear if you meant this to be a vote or


On Thu, Nov 13, 2014 at 4:14 PM, 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
> 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:
> Java docs can be found here:
> Initial Source
> The AzAPI, PEPAPI and other related code can be found on sourceforge:
> AT&T's framework can be found on github:
> Source and Intellectual Property Submission Plan
> 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:
>        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 Freemantle
>        Nominated Mentors
> Emmanuel LĂ©charny
> Colm MacCárthaigh
>        Sponsoring Entity
> The Sponsoring Entity will be the Incubator.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message