-----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
