incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
Date Mon, 05 Jan 2015 18:24:20 GMT

can you please fix the formatting issues? For example,
I can't even tell the exact list of mentors you're proposing.


On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <> wrote:
> 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
> ---------------------------------------------------------------------------------------
> 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
> 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
> 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
> 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:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message