[PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

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: 

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

TBD

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: https://svn.apache.org/repos/asf/incubator/openaz

       Issue Tracking

TBD

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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

[Henry Saputra <he...@gmail.com>]

Ah my bad, I usually use abstract section to get main idea of the proposal.

And as per John request, lets start with DISCUSS thread instead.

- Henry

On Thu, Nov 13, 2014 at 2:59 PM, Hal Lockhart <ha...@oracle.com> wrote:
> Did you see the background section? I meant that to provide that information. I was unclear on how much to assume the audience already knows about the subject.
>
> Hal
>
>> -----Original Message-----
>> From: Henry Saputra [mailto:henry.saputra@gmail.com]
>> Sent: Thursday, November 13, 2014 4:31 PM
>> To: general@incubator.apache.org
>> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
>>
>> Could you add more description on what is PEP and PDP and other
>> acronyms used in the proposal? If it is not directly relevant maybe you
>> can rephrase it to more generic analogy.
>>
>> Thanks,
>>
>> Henry
>>
>> On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart <ha...@oracle.com>
>> wrote:
>> > 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:
>> >
>> > 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
>> >
>> > TBD
>> >
>> > 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: https://svn.apache.org/repos/asf/incubator/openaz
>> >
>> >        Issue Tracking
>> >
>> > TBD
>> >
>> > 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: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

Did you see the background section? I meant that to provide that information. I was unclear on how much to assume the audience already knows about the subject.

Hal

> -----Original Message-----
> From: Henry Saputra [mailto:henry.saputra@gmail.com]
> Sent: Thursday, November 13, 2014 4:31 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> Could you add more description on what is PEP and PDP and other
> acronyms used in the proposal? If it is not directly relevant maybe you
> can rephrase it to more generic analogy.
> 
> Thanks,
> 
> Henry
> 
> On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> > 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:
> >
> > 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
> >
> > TBD
> >
> > 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: https://svn.apache.org/repos/asf/incubator/openaz
> >
> >        Issue Tracking
> >
> > TBD
> >
> > 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: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

[Henry Saputra <he...@gmail.com>]

Could you add more description on what is PEP and PDP and other
acronyms used in the proposal? If it is not directly relevant maybe
you can rephrase it to more generic analogy.

Thanks,

Henry

On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart <ha...@oracle.com> wrote:
> 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:
>
> 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
>
> TBD
>
> 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: https://svn.apache.org/repos/asf/incubator/openaz
>
>        Issue Tracking
>
> TBD
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

[David Jencks <da...@yahoo.com.INVALID>]

It'e really unlikely I will be able to contribute in any way to this any time soon, but I think it would be awesome if this was at apache.  When I tried to investigate xacml a  few years ago the major stumbling block I found was not being able to look at any reasonable implementation.  (I remember something about the sun implementation but for some reason it was not in a form I could learn anything from).

thanks
david jencks

On Nov 13, 2014, at 1:14 PM, Hal Lockhart <ha...@oracle.com> wrote:

> 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: 
> 
> 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
> 
> TBD
> 
> 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: https://svn.apache.org/repos/asf/incubator/openaz
> 
>       Issue Tracking
> 
> TBD
> 
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

[Paul Fremantle <pz...@gmail.com>]

You can treat me as "Paul Free?mantle" in regex form.

Paul

On Fri, Nov 14, 2014 at 1:59 AM, John D. Ament <jo...@gmail.com>
wrote:

> I think so.
>
> There's a few things that you want to iron out first, before people start
> voting on this.
>
> - 3 is generally the "minimum" number of mentors.
> - I can't find a "Paul Freemantle" on the apache committers list.  There's
> a Paul Fremantle, minor spelling difference.
> - You may want to review this section to get a better understanding of the
> goals: http://incubator.apache.org/guides/proposal.html#formulating
>
> the Discuss option just helps everyone look at your proposal a little bit
> better and determine if there's any gotchas.  For example, I'm surprised to
> see a new incubator project using SVN.
>
> - Can you list out your issue tracking preference (should probably be JIRA
> unless you need something else)
> - Please also explicitly list the mailing lists your want.
>
> John
>
> On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
>
> > So you want me to repost the proposal with the Subject changed to start
> > with "[DISCUSS]"? Or should I simply reference the wiki page?
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > Sent: Thursday, November 13, 2014 5:03 PM
> > > To: general@incubator.apache.org
> > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > >
> > > Hal,
> > >
> > > 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 something.
> > >
> > > John
> > >
> > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <hal.lockhart@oracle.com
> >
> > > wrote:
> > >
> > > > 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:
> > > >
> > > > 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
> > > >
> > > > TBD
> > > >
> > > > 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: https://svn.apache.org/repos/asf/incubator/openaz
> > > >
> > > >        Issue Tracking
> > > >
> > > > TBD
> > > >
> > > > 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: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>



-- 
Paul Fremantle
Co-Founder and CTO, WSO2
Member of the Apache Software Foundation
OASIS WS-RX TC Co-chair

blog: http://pzf.fremantle.org
twitter: @pzfreo

RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

My  apologies.

Hal

> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, November 14, 2014 11:10 AM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> It will be cool to see a XACML project at Apache, especially one that
> looks certain to be the main open source implementation. One minor
> correction:
> 
> > Colm MacCárthaigh
> 
> You have the wrong Apache Colm there :-)
> 
> Colm (O hEigeartaigh)
> 
> On Fri, Nov 14, 2014 at 1:55 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> 
> > I was not questioning whether to initiate discussion. That was what I
> > was trying to do.
> >
> > I was asking how to go about it.
> >
> > Thanks for the comments, they are noted.
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > Sent: Thursday, November 13, 2014 8:59 PM
> > > To: general@incubator.apache.org
> > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > >
> > > I think so.
> > >
> > > There's a few things that you want to iron out first, before people
> > > start voting on this.
> > >
> > > - 3 is generally the "minimum" number of mentors.
> > > - I can't find a "Paul Freemantle" on the apache committers list.
> > > There's a Paul Fremantle, minor spelling difference.
> > > - You may want to review this section to get a better understanding
> > > of the
> > > goals: http://incubator.apache.org/guides/proposal.html#formulating
> > >
> > > the Discuss option just helps everyone look at your proposal a
> > > little bit better and determine if there's any gotchas.  For
> > > example, I'm surprised to see a new incubator project using SVN.
> > >
> > > - Can you list out your issue tracking preference (should probably
> > > be JIRA unless you need something else)
> > > - Please also explicitly list the mailing lists your want.
> > >
> > > John
> > >
> > > On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart
> > > <ha...@oracle.com>
> > > wrote:
> > >
> > > > So you want me to repost the proposal with the Subject changed to
> > > > start with "[DISCUSS]"? Or should I simply reference the wiki
> page?
> > > >
> > > > Hal
> > > >
> > > > > -----Original Message-----
> > > > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > > > Sent: Thursday, November 13, 2014 5:03 PM
> > > > > To: general@incubator.apache.org
> > > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > > > >
> > > > > Hal,
> > > > >
> > > > > 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 something.
> > > > >
> > > > > John
> > > > >
> > > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart
> > > > > <ha...@oracle.com>
> > > > > wrote:
> > > > >
> > > > > > 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:
> > > > > >
> > > > > > 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/do
> > > > > c/
> > > > > > 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
> > > > > >
> > > > > > TBD
> > > > > >
> > > > > > 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: https://svn.apache.org/repos/asf/incubator/openaz
> > > > > >
> > > > > >        Issue Tracking
> > > > > >
> > > > > > TBD
> > > > > >
> > > > > > 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:
> > > > > > general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-
> > > help@incubator.apache.org
> > > > > >
> > > > > >
> > > >
> > > > -----------------------------------------------------------------
> -
> > > > --- To unsubscribe, e-mail:
> > > > general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-
> help@incubator.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> 
> 
> --
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

[Colm O hEigeartaigh <co...@apache.org>]

It will be cool to see a XACML project at Apache, especially one that looks
certain to be the main open source implementation. One minor correction:

> Colm MacCárthaigh

You have the wrong Apache Colm there :-)

Colm (O hEigeartaigh)

On Fri, Nov 14, 2014 at 1:55 PM, Hal Lockhart <ha...@oracle.com>
wrote:

> I was not questioning whether to initiate discussion. That was what I was
> trying to do.
>
> I was asking how to go about it.
>
> Thanks for the comments, they are noted.
>
> Hal
>
> > -----Original Message-----
> > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > Sent: Thursday, November 13, 2014 8:59 PM
> > To: general@incubator.apache.org
> > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> >
> > I think so.
> >
> > There's a few things that you want to iron out first, before people
> > start voting on this.
> >
> > - 3 is generally the "minimum" number of mentors.
> > - I can't find a "Paul Freemantle" on the apache committers list.
> > There's a Paul Fremantle, minor spelling difference.
> > - You may want to review this section to get a better understanding of
> > the
> > goals: http://incubator.apache.org/guides/proposal.html#formulating
> >
> > the Discuss option just helps everyone look at your proposal a little
> > bit better and determine if there's any gotchas.  For example, I'm
> > surprised to see a new incubator project using SVN.
> >
> > - Can you list out your issue tracking preference (should probably be
> > JIRA unless you need something else)
> > - Please also explicitly list the mailing lists your want.
> >
> > John
> >
> > On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart <ha...@oracle.com>
> > wrote:
> >
> > > So you want me to repost the proposal with the Subject changed to
> > > start with "[DISCUSS]"? Or should I simply reference the wiki page?
> > >
> > > Hal
> > >
> > > > -----Original Message-----
> > > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > > Sent: Thursday, November 13, 2014 5:03 PM
> > > > To: general@incubator.apache.org
> > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > > >
> > > > Hal,
> > > >
> > > > 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 something.
> > > >
> > > > John
> > > >
> > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart
> > > > <ha...@oracle.com>
> > > > wrote:
> > > >
> > > > > 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:
> > > > >
> > > > > 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/do
> > > > c/
> > > > > 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
> > > > >
> > > > > TBD
> > > > >
> > > > > 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: https://svn.apache.org/repos/asf/incubator/openaz
> > > > >
> > > > >        Issue Tracking
> > > > >
> > > > > TBD
> > > > >
> > > > > 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:
> > > > > general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-
> > help@incubator.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

I was not questioning whether to initiate discussion. That was what I was trying to do.

I was asking how to go about it.

Thanks for the comments, they are noted.

Hal

> -----Original Message-----
> From: John D. Ament [mailto:john.d.ament@gmail.com]
> Sent: Thursday, November 13, 2014 8:59 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> I think so.
> 
> There's a few things that you want to iron out first, before people
> start voting on this.
> 
> - 3 is generally the "minimum" number of mentors.
> - I can't find a "Paul Freemantle" on the apache committers list.
> There's a Paul Fremantle, minor spelling difference.
> - You may want to review this section to get a better understanding of
> the
> goals: http://incubator.apache.org/guides/proposal.html#formulating
> 
> the Discuss option just helps everyone look at your proposal a little
> bit better and determine if there's any gotchas.  For example, I'm
> surprised to see a new incubator project using SVN.
> 
> - Can you list out your issue tracking preference (should probably be
> JIRA unless you need something else)
> - Please also explicitly list the mailing lists your want.
> 
> John
> 
> On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> 
> > So you want me to repost the proposal with the Subject changed to
> > start with "[DISCUSS]"? Or should I simply reference the wiki page?
> >
> > Hal
> >
> > > -----Original Message-----
> > > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > > Sent: Thursday, November 13, 2014 5:03 PM
> > > To: general@incubator.apache.org
> > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> > >
> > > Hal,
> > >
> > > 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 something.
> > >
> > > John
> > >
> > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart
> > > <ha...@oracle.com>
> > > wrote:
> > >
> > > > 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:
> > > >
> > > > 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/do
> > > c/
> > > > 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
> > > >
> > > > TBD
> > > >
> > > > 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: https://svn.apache.org/repos/asf/incubator/openaz
> > > >
> > > >        Issue Tracking
> > > >
> > > > TBD
> > > >
> > > > 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:
> > > > general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-
> help@incubator.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

["John D. Ament" <jo...@gmail.com>]

I think so.

There's a few things that you want to iron out first, before people start
voting on this.

- 3 is generally the "minimum" number of mentors.
- I can't find a "Paul Freemantle" on the apache committers list.  There's
a Paul Fremantle, minor spelling difference.
- You may want to review this section to get a better understanding of the
goals: http://incubator.apache.org/guides/proposal.html#formulating

the Discuss option just helps everyone look at your proposal a little bit
better and determine if there's any gotchas.  For example, I'm surprised to
see a new incubator project using SVN.

- Can you list out your issue tracking preference (should probably be JIRA
unless you need something else)
- Please also explicitly list the mailing lists your want.

John

On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart <ha...@oracle.com>
wrote:

> So you want me to repost the proposal with the Subject changed to start
> with "[DISCUSS]"? Or should I simply reference the wiki page?
>
> Hal
>
> > -----Original Message-----
> > From: John D. Ament [mailto:john.d.ament@gmail.com]
> > Sent: Thursday, November 13, 2014 5:03 PM
> > To: general@incubator.apache.org
> > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> >
> > Hal,
> >
> > 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 something.
> >
> > John
> >
> > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <ha...@oracle.com>
> > wrote:
> >
> > > 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:
> > >
> > > 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
> > >
> > > TBD
> > >
> > > 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: https://svn.apache.org/repos/asf/incubator/openaz
> > >
> > >        Issue Tracking
> > >
> > > TBD
> > >
> > > 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: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

So you want me to repost the proposal with the Subject changed to start with "[DISCUSS]"? Or should I simply reference the wiki page?

Hal

> -----Original Message-----
> From: John D. Ament [mailto:john.d.ament@gmail.com]
> Sent: Thursday, November 13, 2014 5:03 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> Hal,
> 
> 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 something.
> 
> John
> 
> On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> 
> > 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:
> >
> > 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
> >
> > TBD
> >
> > 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: https://svn.apache.org/repos/asf/incubator/openaz
> >
> >        Issue Tracking
> >
> > TBD
> >
> > 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: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: [PROPOSAL] OpenAZ as new Incubator project

[Hal Lockhart <ha...@oracle.com>]

No, I am sorry this process is all new to me.

I also created a page in the wiki with same content. (OpenAZProposal)

Do I need to do something or can you cancel it?

Hal

> -----Original Message-----
> From: John D. Ament [mailto:john.d.ament@gmail.com]
> Sent: Thursday, November 13, 2014 5:03 PM
> To: general@incubator.apache.org
> Subject: Re: [PROPOSAL] OpenAZ as new Incubator project
> 
> Hal,
> 
> 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 something.
> 
> John
> 
> On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <ha...@oracle.com>
> wrote:
> 
> > 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:
> >
> > 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
> >
> > TBD
> >
> > 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: https://svn.apache.org/repos/asf/incubator/openaz
> >
> >        Issue Tracking
> >
> > TBD
> >
> > 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: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [PROPOSAL] OpenAZ as new Incubator project

["John D. Ament" <jo...@gmail.com>]

Hal,

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

John

On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart <ha...@oracle.com>
wrote:

> 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:
>
> 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
>
> TBD
>
> 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: https://svn.apache.org/repos/asf/incubator/openaz
>
>        Issue Tracking
>
> TBD
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>