incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hill, Richard C" <>
Subject Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
Date Tue, 13 Jan 2015 15:44:31 GMT

I call a vote to accept OpenAz as a new Incubator project.

The proposal can be found here:

and is included below in this email.

Voting will remain open until at least January 20, 2015 23:00 ET.

Hal Lockhart



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.


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

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.


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.


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


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.


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>


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.


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

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.


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

Git Directory

We propose:

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


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.



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:
For additional commands, e-mail:

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