-----Original Message-----
From: Roman Shaposhnik [mailto:ro...@shaposhnik.org]
Sent: Monday, January 05, 2015 1:24 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
into the Apache Incubator
Hi!
can you please fix the formatting issues? For example, I can't even
tell the exact list of mentors you're proposing.
Thanks,
Roman.
On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <hal.lockh...@oracle.com>
wrote:
I call a vote to accept OpenAz as a new Incubator project.
The proposal can be found here:
https://wiki.apache.org/incubator/OpenAZProposal
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 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
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:
https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
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: 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
