[VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

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

The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal

and is included below in this email.

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

Hal Lockhart

---------------------------------------------------------------------------------------

Abstract

OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard.

Proposal

Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem.

Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent.

The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation.

Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability.

A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one.

Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope.

AT&T has recently contributed their extensive XACML framework to the project.

The AT&T framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The AT&T PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API.

The AT&T framework also includes interfaces and implementations to standardize development of PIP engines that are used by the AT&T PDP implementation, and can be used by other implementations built on top of the AT&T framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation.

Background

Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface and other software. This makes it difficult to understand, modify, analyze or even locate the security policy. The primary challenge of Access Control is striking the right balance between powerful expression and intelligibility to human beings.

The OASIS XACML Standard exemplifies Attribute-Based Access Control (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other components. The Policy Enforcement Point (PEP) must be located so as to be able to enforce the decision, typically near the resource. The PEP first asks the PDP if access should be allowed and provides data, in the form of Attributes, to be used as input to the policies held by the PDP.

In addition to responding permit or deny, XACML allows a policy to emit Obligations or Advice, which direct the PEP to do certain things, such logging the access or failure or promising to get rid of the data after 30 days.

Attributes are identified as being in a certain category which represents one element in the proposed access. For example attributes may be associated with the resource being accessed, the action being taken or the environment, .e.g. date/time. Attributes may also be associated with any or several types of Subjects, which represent the active parties to the access, such as the requester, intermediaries, the recipient (if different), the codebase, the machine executing the code.

Attributes may be provided by the PEP and usually at least a few are, but Attributes may also added by other components of the system. It is also possible for a PDP to add attributes in the middle of policy evaluation. All of these obtain Attributes from the Policy Information Point (PIP).

The Policy Administration Point (PAP) creates policies and manages then through their life cycles and generally the entire infrastructure.

The XACML language is essentially a set of expressions which evaluate to a Boolean. If true the policy is said to be applicable. The Policy contains permit or deny and may include Permissions and or Advice. If policies disagree we resolve the conflict with combining algorithms. XACML provides some standard ones and you can implement your own. Mostly they are common sense like drop non-applicable polices. A commonly used algorithm is default deny. Deny overrides permit.

Rationale

Access Control may be the most basic security service, but for the most part it remains primitive in practice. While other services like message protection and authentication have seen many advances in recent years and decades, deployed access control systems are opaque, difficult to us and harder to manage. Most organizations claim that they have security policies, protect privacy and accurately report financial results, but in practice they have no real way of discovering whether their systems actually behave the way they are alleged to do.

Just the foreground problems relating to deploying practical ABAC systems make a formidable list. If only the PDP knows what the policies are, how do we make sure it gets the attributes it needs to evaluate policies? How can we name organize, register and dispatch Obligations and Advice, allowing handlers to be provided by the system and added by users? How can the XACML 3.0 feature of being able to create your own attribute categories best be supported by the infrastructure and utilized by users? What are the best ways to create and test policies? What tools will best help us analyze the effects of the policies in force?

However, new requirements are rapidly being introduced and need to be met. Privacy requirements continue to increase in complexity and scope. Data which moves around, such as documents, need to be protected. We need secure ways to delegate authority without undermining the integrity of the access control system. New applications, business and social relationships are driving the need for new policy and delegation capabilities.

We believe that the way to meet these challenges is to get more people actively engaged in using what is currently available so they can understand its limitations and make it better. We need to make it far easier to get a basic access control infrastructure up and running. We need more people who are familiar with XACML the way many people are familiar with SQL. If as some people say, XACML is the assembly language of access control, we need the real world experience with it that will lead us to the useful abstractions that can be implemented in higher level languages and other tools.

Initial Goals

Work is currently underway to extend the PEPAPI and increase its flexibility. Since it does not directly correspond to any standard the way AzAPI does, it is necessary to struggle with the issues of what to expose and what to hide from consumers of the API.

Other work in progress involves the architecture of Obligations and Advice. There is also an effort to develop a remote client which can easily be dropped into any Java environment and make decision requests of any commercial or open source XACML PDP.

The contribution of AT&T's framework creates a need to integrate the prior work with it. Most of the focus will be on AzAPI and the corresponding AT&T API, which do largely the same thing. The result is likely to be a synthesis, since each has features the other lacks. Then PEPAPI will need to be integrated with the new API. The AT&T PDP and PAP will be incorporated as is. There has been some parallel work done in the area of PIPs. Work will be required to understand how to proceed here.

Current Status

Meritocracy

The project was started by Prateek Mishra, Rich Levinson and Hal Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013 Duanhua Tu and Ajith Nair contributed code both using and extending AzAPI and PEPAPI and incorporating PIPs using the AMF as originally proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam Dragosh and Chris Rath contributed the XACML infrastructure they had developed at AT&T.

During most of its history the project has been very small and has made decisions by informal consensus. Major design issues have been decided by open debate. Minor issues and experimental proposals have been openly welcomed. Several of the participants have a background in open consensus-based standards making.

In addition to the mailing list, the project has regular phone calls every other Thursday.

Community

The original focus of the project was to attract developers of XACML products, either individuals or corporations, and to build alignment among vendors on a common API that could simplify technical integration for their customers. As OpenAz has matured, our community has grown to include application developers working to adopt and deploy XACML in their applications. So, for example, contributions reflect what individual developers have learned in vertical industries such as financial services, healthcare, and computing and communications services, and our APIs and internal component architecture have evolved to reflect a strong practical understanding of what it takes to deploy XACML applications in a large organization.

Core Developers

The following developers have written most of the code to date.

Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson < rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at jpmchase dot com> Chris Rath <car at research dot att dot com> Duanhua Tu <duanhua.tu at jpmchase dot com>

The following people made other significant technical contributions.

David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at oracle dot com>

Alignment

It has always been a goal to make OpenAz an Apache project. The Apache license was used for all contributions. We believe the project has now reached a critical size in terms of developers, organizations and contributed code to make it appropriate to make a proposal to the Incubator.

Known Risks

Orphaned Projects

Given the small size of the project, there is a risk of the project being orphaned. There seems to be strong interest in the use of our tools, which should markedly increase with the contribution of the AT&T code. "Where can I get an open source PDP?" and "where can I get an open source policy editor?" are frequent questions on XACML mailing lists.

Inexperience with Open Source

While few of the developers have extensive experience with open source, a number of us have long experience in standards making in open consensus-based environments. For example the XACML TC has operated since 2001 based on consensus building, with few, if any votes which were not unanimous. The main challenge to the project will be managing the process with more participants and a more formal process.

Homogeneous Developers

Currently all the contributors are employees either of companies offering an XACML product or large end users deploying XACML technology for internal use. The positive aspect is that they are all highly experienced senior developers used to operating in a disciplined environment. The disadvantage is that the focus to date has mostly been problems that arise in large scale environments typified by the infrastructure of large corporations.

Reliance on Salaried Developers

All current committers are salaried developers. However the organizations they work for have a long term commitment to the technology. We hope that in the Apache foundation we will be able to attract new developers to help us address the many fascinating unsolved technological problems associated with deploying ABAC.

Relationship with other Apache Projects

As far as we can determine, no existing Apache project overlaps with OpenAz in its goals of the technology developed so far. However, beyond the immediate project goals there are many potential opportunities for integration with existing Apache projects. Shiro, Turbine and WSS4J are Java frameworks which could incorporate XACML as the policy language using OpenAz components. Manifold CF, Qpid and Archiva already have hooks to incorporate external access control systems.

An Excessive Fascination with the Apache Brand

We hope that becoming an Apache project will not only attract new participants to OpenAz, but will draw attention to the neglected field of access control. As previously stated it has always been our goal to join Apache, the only question was when the time was ripe.

Documentation

The OpenAz web site is:

http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page

Java docs can be found here:

http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/index.html

Initial Source

The AzAPI, PEPAPI and other related code can be found on sourceforge:

http://openaz.svn.sourceforge.net/viewvc/openaz/

AT&T's framework can be found on github:

https://github.com/att/XACML

Source and Intellectual Property Submission Plan

All the OpenAz code has been submitted under the Apache 2.0 license. The AT&T software is available under the MIT license. Over time the project will move to a single license.

External Dependencies

There aren't any we are aware of.

Cryptography

OpenAz does not provide any cryptographic capabilities. The XACML Standard does specify some uses of cryptography directly, e.g. digital signatures over policies and others by implication, e.g. authentication via cryptography.

Required Resources

Mailing lists

The standard lists should be sufficient at the current time.The mailing list name will be openaz.

Git Directory

We propose: https://git-wip-us.apache.org/repos/asf/incubator-openaz.git

Issue Tracking

The project will use JIRA for issue tracking.

Initial Committers

Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu Ajith Nair Srijith Nair Pam Dragosh Chris Rath

Affiliations

Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.

Sponsors

Champion

Paul Fremantle

Nominated Mentors

Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea

Sponsoring Entity

The Sponsoring Entity will be the Incubator.

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

[RESULT] [VOTE] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

Vote passes with:

[6] +1 (binding): hadrian, coheigea, elecharny, pzf, adc, jani

[6] +1 (non-binding): chris rath, rich levinson, pam dragosh, dilli arumungam, david laurance, hal lockhart

[0] -1:

Congratulations and good luck to the OpenAZ community.

Hal

> -----Original Message-----
> From: Hal Lockhart
> Sent: Monday, January 05, 2015 1:16 PM
> To: general@incubator.apache.org
> Subject: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into
> the Apache Incubator
> 
> I call a vote to accept OpenAz as a new Incubator project.
> 
> The proposal can be found here:
> https://wiki.apache.org/incubator/OpenAZProposal
> 
> and is included below in this email.
> 
> Voting will remain open until at least January 20, 2015 23:00 ET.
> 
> Hal Lockhart
> 
> -----------------------------------------------------------------------
> ----------------
> 
> Abstract
> 
> OpenAz is a project to create tools and libraries to enable the
> development of Attribute-based Access Control (ABAC) Systems in a
> variety of languages. In general the work is at least consistent with
> or actually conformant to the OASIS XACML Standard.
> 
> Proposal
> 
> Generally the work falls into two categories: ready to use tools which
> implement standardized or well understood components of an ABAC system
> and design proposals and proof of concept code relating to less well
> understood or experimental aspects of the problem.
> 
> Much of the work to date has revolved around defining interfaces
> enabling a PEP to request an access control decision from a PDP. The
> XACML standard defines an abstract request format in xml and protocol
> wire formats in xaml and json, but it does not specify programmatic
> interfaces in any language. The standard says that the use of XML (or
> JSON) is not required only the semantic equivalent.
> 
> The first Interface, AzAPI is modeled closely on the XACML defined
> interface, expressed in Java. One of the goals was to support calls to
> both a PDP local to the same process and a PDP in a remote server.
> AzAPI includes the interface, reference code to handle things like the
> many supported datatypes in XACML and glue code to mate it to the open
> source Sun XACML implementation.
> 
> Because of the dependence on Sun XACML (which is XACML 2.0) the
> interface was missing some XACML 3.0 features. More recently this was
> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
> done by the JPMC team to support calling a remote PDP. WSo2 is also
> pursuing this capability.
> 
> A second, higher level interface, PEPAPI was also defined. PEPAPI is
> more intended for application developers with little knowledge of
> XACML. It allows Java objects which contain attribute information to be
> passed in. Conversion methods, called mappers extract information from
> the objects and present it in the format expected by XACML. Some
> implementers have chosen to implement PEPAPI directly against their
> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
> which closely matches the Java one.
> 
> Examples of more speculative work include: proposals for registration
> and dispatch of Obligation and Advice handlers, a scheme called AMF to
> tell PIPs how to retrieve attributes and PIP code to implement it,
> discussion of PoC code to demonstrate the use of XACML policies to
> drive OAuth interations and a proposal to use XACML policies to express
> OAuth scope.
> 
> AT&T has recently contributed their extensive XACML framework to the
> project.
> 
> The AT&T framework represents the entire XACML 3.0 object set as a
> collection of Java interfaces and standard implementations of those
> interfaces. The AT&T PDP engine is built on top of this framework and
> represents a complete implementation of a XACML 3.0 PDP, including all
> of the multi-decision profiles. In addition, the framework also
> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> functionality, allowing application developers to simply annotate a
> Java class to provide attributes for a request. The annotation support
> removes the need for application developers to learn much of the API.
> 
> The AT&T framework also includes interfaces and implementations to
> standardize development of PIP engines that are used by the AT&T PDP
> implementation, and can be used by other implementations built on top
> of the AT&T framework. The framework also includes interfaces and
> implementations for a PAP distributed cloud infrastructure of PDP nodes
> that includes support for policy distribution and pip configurations.
> This PAP infrastructure includes a web application administrative
> console that contains a XACML 3.0 policy editor, attribute dictionary
> support, and management of PDP RESTful node instances. In addition,
> there are tools available for policy simulation.
> 
> Background
> 
> Access Control is in some ways the most basic IT Security service. It
> consists of making a decision about whether a particular request should
> be allowed and enforcing that decision. Aside from schemes like
> permission bits and Access Control Lists (ACLs) the most common way
> access control is implemented is as code in a server or application
> which typically intertwines access control logic with business logic,
> User interface and other software. This makes it difficult to
> understand, modify, analyze or even locate the security policy. The
> primary challenge of Access Control is striking the right balance
> between powerful expression and intelligibility to human beings.
> 
> The OASIS XACML Standard exemplifies Attribute-Based Access Control
> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
> components. The Policy Enforcement Point (PEP) must be located so as to
> be able to enforce the decision, typically near the resource. The PEP
> first asks the PDP if access should be allowed and provides data, in
> the form of Attributes, to be used as input to the policies held by the
> PDP.
> 
> In addition to responding permit or deny, XACML allows a policy to emit
> Obligations or Advice, which direct the PEP to do certain things, such
> logging the access or failure or promising to get rid of the data after
> 30 days.
> 
> Attributes are identified as being in a certain category which
> represents one element in the proposed access. For example attributes
> may be associated with the resource being accessed, the action being
> taken or the environment, .e.g. date/time. Attributes may also be
> associated with any or several types of Subjects, which represent the
> active parties to the access, such as the requester, intermediaries,
> the recipient (if different), the codebase, the machine executing the
> code.
> 
> Attributes may be provided by the PEP and usually at least a few are,
> but Attributes may also added by other components of the system. It is
> also possible for a PDP to add attributes in the middle of policy
> evaluation. All of these obtain Attributes from the Policy Information
> Point (PIP).
> 
> The Policy Administration Point (PAP) creates policies and manages then
> through their life cycles and generally the entire infrastructure.
> 
> The XACML language is essentially a set of expressions which evaluate
> to a Boolean. If true the policy is said to be applicable. The Policy
> contains permit or deny and may include Permissions and or Advice. If
> policies disagree we resolve the conflict with combining algorithms.
> XACML provides some standard ones and you can implement your own.
> Mostly they are common sense like drop non-applicable polices. A
> commonly used algorithm is default deny. Deny overrides permit.
> 
> Rationale
> 
> Access Control may be the most basic security service, but for the most
> part it remains primitive in practice. While other services like
> message protection and authentication have seen many advances in recent
> years and decades, deployed access control systems are opaque,
> difficult to us and harder to manage. Most organizations claim that
> they have security policies, protect privacy and accurately report
> financial results, but in practice they have no real way of discovering
> whether their systems actually behave the way they are alleged to do.
> 
> Just the foreground problems relating to deploying practical ABAC
> systems make a formidable list. If only the PDP knows what the policies
> are, how do we make sure it gets the attributes it needs to evaluate
> policies? How can we name organize, register and dispatch Obligations
> and Advice, allowing handlers to be provided by the system and added by
> users? How can the XACML 3.0 feature of being able to create your own
> attribute categories best be supported by the infrastructure and
> utilized by users? What are the best ways to create and test policies?
> What tools will best help us analyze the effects of the policies in
> force?
> 
> However, new requirements are rapidly being introduced and need to be
> met. Privacy requirements continue to increase in complexity and scope.
> Data which moves around, such as documents, need to be protected. We
> need secure ways to delegate authority without undermining the
> integrity of the access control system. New applications, business and
> social relationships are driving the need for new policy and delegation
> capabilities.
> 
> We believe that the way to meet these challenges is to get more people
> actively engaged in using what is currently available so they can
> understand its limitations and make it better. We need to make it far
> easier to get a basic access control infrastructure up and running. We
> need more people who are familiar with XACML the way many people are
> familiar with SQL. If as some people say, XACML is the assembly
> language of access control, we need the real world experience with it
> that will lead us to the useful abstractions that can be implemented in
> higher level languages and other tools.
> 
> Initial Goals
> 
> Work is currently underway to extend the PEPAPI and increase its
> flexibility. Since it does not directly correspond to any standard the
> way AzAPI does, it is necessary to struggle with the issues of what to
> expose and what to hide from consumers of the API.
> 
> Other work in progress involves the architecture of Obligations and
> Advice. There is also an effort to develop a remote client which can
> easily be dropped into any Java environment and make decision requests
> of any commercial or open source XACML PDP.
> 
> The contribution of AT&T's framework creates a need to integrate the
> prior work with it. Most of the focus will be on AzAPI and the
> corresponding AT&T API, which do largely the same thing. The result is
> likely to be a synthesis, since each has features the other lacks. Then
> PEPAPI will need to be integrated with the new API. The AT&T PDP and
> PAP will be incorporated as is. There has been some parallel work done
> in the area of PIPs. Work will be required to understand how to proceed
> here.
> 
> Current Status
> 
> Meritocracy
> 
> The project was started by Prateek Mishra, Rich Levinson and Hal
> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> Duanhua Tu and Ajith Nair contributed code both using and extending
> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
> Dragosh and Chris Rath contributed the XACML infrastructure they had
> developed at AT&T.
> 
> During most of its history the project has been very small and has made
> decisions by informal consensus. Major design issues have been decided
> by open debate. Minor issues and experimental proposals have been
> openly welcomed. Several of the participants have a background in open
> consensus-based standards making.
> 
> In addition to the mailing list, the project has regular phone calls
> every other Thursday.
> 
> Community
> 
> The original focus of the project was to attract developers of XACML
> products, either individuals or corporations, and to build alignment
> among vendors on a common API that could simplify technical integration
> for their customers. As OpenAz has matured, our community has grown to
> include application developers working to adopt and deploy XACML in
> their applications. So, for example, contributions reflect what
> individual developers have learned in vertical industries such as
> financial services, healthcare, and computing and communications
> services, and our APIs and internal component architecture have evolved
> to reflect a strong practical understanding of what it takes to deploy
> XACML applications in a large organization.
> 
> Core Developers
> 
> The following developers have written most of the code to date.
> 
> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> jpmchase dot com> Chris Rath <car at research dot att dot com> Duanhua
> Tu <duanhua.tu at jpmchase dot com>
> 
> The following people made other significant technical contributions.
> 
> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> oracle dot com>
> 
> Alignment
> 
> It has always been a goal to make OpenAz an Apache project. The Apache
> license was used for all contributions. We believe the project has now
> reached a critical size in terms of developers, organizations and
> contributed code to make it appropriate to make a proposal to the
> Incubator.
> 
> Known Risks
> 
> Orphaned Projects
> 
> Given the small size of the project, there is a risk of the project
> being orphaned. There seems to be strong interest in the use of our
> tools, which should markedly increase with the contribution of the AT&T
> code. "Where can I get an open source PDP?" and "where can I get an
> open source policy editor?" are frequent questions on XACML mailing
> lists.
> 
> Inexperience with Open Source
> 
> While few of the developers have extensive experience with open source,
> a number of us have long experience in standards making in open
> consensus-based environments. For example the XACML TC has operated
> since 2001 based on consensus building, with few, if any votes which
> were not unanimous. The main challenge to the project will be managing
> the process with more participants and a more formal process.
> 
> Homogeneous Developers
> 
> Currently all the contributors are employees either of companies
> offering an XACML product or large end users deploying XACML technology
> for internal use. The positive aspect is that they are all highly
> experienced senior developers used to operating in a disciplined
> environment. The disadvantage is that the focus to date has mostly been
> problems that arise in large scale environments typified by the
> infrastructure of large corporations.
> 
> Reliance on Salaried Developers
> 
> All current committers are salaried developers. However the
> organizations they work for have a long term commitment to the
> technology. We hope that in the Apache foundation we will be able to
> attract new developers to help us address the many fascinating unsolved
> technological problems associated with deploying ABAC.
> 
> Relationship with other Apache Projects
> 
> As far as we can determine, no existing Apache project overlaps with
> OpenAz in its goals of the technology developed so far. However, beyond
> the immediate project goals there are many potential opportunities for
> integration with existing Apache projects. Shiro, Turbine and WSS4J are
> Java frameworks which could incorporate XACML as the policy language
> using OpenAz components. Manifold CF, Qpid and Archiva already have
> hooks to incorporate external access control systems.
> 
> An Excessive Fascination with the Apache Brand
> 
> We hope that becoming an Apache project will not only attract new
> participants to OpenAz, but will draw attention to the neglected field
> of access control. As previously stated it has always been our goal to
> join Apache, the only question was when the time was ripe.
> 
> Documentation
> 
> The OpenAz web site is:
> 
> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> 
> Java docs can be found here:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/i
> ndex.html
> 
> Initial Source
> 
> The AzAPI, PEPAPI and other related code can be found on sourceforge:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/
> 
> AT&T's framework can be found on github:
> 
> https://github.com/att/XACML
> 
> Source and Intellectual Property Submission Plan
> 
> All the OpenAz code has been submitted under the Apache 2.0 license.
> The AT&T software is available under the MIT license. Over time the
> project will move to a single license.
> 
> External Dependencies
> 
> There aren't any we are aware of.
> 
> Cryptography
> 
> OpenAz does not provide any cryptographic capabilities. The XACML
> Standard does specify some uses of cryptography directly, e.g. digital
> signatures over policies and others by implication, e.g. authentication
> via cryptography.
> 
> Required Resources
> 
> Mailing lists
> 
> The standard lists should be sufficient at the current time.The mailing
> list name will be openaz.
> 
> Git Directory
> 
> We propose: https://git-wip-us.apache.org/repos/asf/incubator-
> openaz.git
> 
> Issue Tracking
> 
> The project will use JIRA for issue tracking.
> 
> Initial Committers
> 
> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> 
> Affiliations
> 
> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> 
> Sponsors
> 
> Champion
> 
> Paul Fremantle
> 
> Nominated Mentors
> 
> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> 
> Sponsoring Entity
> 
> The Sponsoring Entity will be the Incubator.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Mon, Jan 5, 2015 at 7:27 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> I made some cosmetic changes to the list of committers and mentors. It
> should be clear now.

Thanks!

Roman.

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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[rich levinson <ri...@oracle.com>]

+1

On 1/6/2015 12:44 PM, RATH, CHRISTOPHER A (CHRISTOPHER A) wrote:
> +1.
>
> --
> Christopher A. Rath
> Director Inventive Science – Intelligent Systems Research Department
>
> -----Original Message-----
> From: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
> Sent: Monday, January 05, 2015 10:28 PM
> To: general@incubator.apache.org
> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
>
> +1.
>
> I made some cosmetic changes to the list of committers and mentors. It should be clear now.
>
> Hadrian
>
>
> On 01/05/2015 02:04 PM, Hal Lockhart wrote:
>> I added a comma and the word "and" to the Mentors section. The Mentors are:
>>
>> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>>
>> Do you see any other formatting errors?
>>
>> Hal
>>
>>> -----Original Message-----
>>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>>> Sent: Monday, January 05, 2015 1:24 PM
>>> To: general@incubator.apache.org
>>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>>> into the Apache Incubator
>>>
>>> Hi!
>>>
>>> can you please fix the formatting issues? For example, I can't even
>>> tell the exact list of mentors you're proposing.
>>>
>>> Thanks,
>>> Roman.
>>>
>>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart
>>> <ha...@oracle.com>
>>> wrote:
>>>> I call a vote to accept OpenAz as a new Incubator project.
>>>>
>>>> The proposal can be found here:
>>>> https://wiki.apache.org/incubator/OpenAZProposal
>>>>
>>>> and is included below in this email.
>>>>
>>>> Voting will remain open until at least January 20, 2015 23:00 ET.
>>>>
>>>> Hal Lockhart
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>> -
>>>> -----------------
>>>>
>>>> Abstract
>>>>
>>>> OpenAz is a project to create tools and libraries to enable the
>>> development of Attribute-based Access Control (ABAC) Systems in a
>>> variety of languages. In general the work is at least consistent with
>>> or actually conformant to the OASIS XACML Standard.
>>>> Proposal
>>>>
>>>> Generally the work falls into two categories: ready to use tools
>>> which implement standardized or well understood components of an ABAC
>>> system and design proposals and proof of concept code relating to
>>> less well understood or experimental aspects of the problem.
>>>> Much of the work to date has revolved around defining interfaces
>>> enabling a PEP to request an access control decision from a PDP. The
>>> XACML standard defines an abstract request format in xml and protocol
>>> wire formats in xaml and json, but it does not specify programmatic
>>> interfaces in any language. The standard says that the use of XML (or
>>> JSON) is not required only the semantic equivalent.
>>>> The first Interface, AzAPI is modeled closely on the XACML defined
>>> interface, expressed in Java. One of the goals was to support calls
>>> to both a PDP local to the same process and a PDP in a remote server.
>>> AzAPI includes the interface, reference code to handle things like
>>> the many supported datatypes in XACML and glue code to mate it to the
>>> open source Sun XACML implementation.
>>>> Because of the dependence on Sun XACML (which is XACML 2.0) the
>>> interface was missing some XACML 3.0 features. More recently this was
>>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>>> pursuing this capability.
>>>> A second, higher level interface, PEPAPI was also defined. PEPAPI is
>>> more intended for application developers with little knowledge of
>>> XACML. It allows Java objects which contain attribute information to
>>> be passed in. Conversion methods, called mappers extract information
>>> from the objects and present it in the format expected by XACML. Some
>>> implementers have chosen to implement PEPAPI directly against their
>>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>>> which closely matches the Java one.
>>>> Examples of more speculative work include: proposals for
>>>> registration
>>> and dispatch of Obligation and Advice handlers, a scheme called AMF
>>> to tell PIPs how to retrieve attributes and PIP code to implement it,
>>> discussion of PoC code to demonstrate the use of XACML policies to
>>> drive OAuth interations and a proposal to use XACML policies to
>>> express OAuth scope.
>>>> AT&T has recently contributed their extensive XACML framework to the
>>> project.
>>>> The AT&T framework represents the entire XACML 3.0 object set as a
>>> collection of Java interfaces and standard implementations of those
>>> interfaces. The AT&T PDP engine is built on top of this framework and
>>> represents a complete implementation of a XACML 3.0 PDP, including
>>> all of the multi-decision profiles. In addition, the framework also
>>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0
>>> and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>>> functionality, allowing application developers to simply annotate a
>>> Java class to provide attributes for a request. The annotation
>>> support removes the need for application developers to learn much of the API.
>>>> The AT&T framework also includes interfaces and implementations to
>>> standardize development of PIP engines that are used by the AT&T PDP
>>> implementation, and can be used by other implementations built on top
>>> of the AT&T framework. The framework also includes interfaces and
>>> implementations for a PAP distributed cloud infrastructure of PDP
>>> nodes that includes support for policy distribution and pip configurations.
>>> This PAP infrastructure includes a web application administrative
>>> console that contains a XACML 3.0 policy editor, attribute dictionary
>>> support, and management of PDP RESTful node instances. In addition,
>>> there are tools available for policy simulation.
>>>> Background
>>>>
>>>> Access Control is in some ways the most basic IT Security service.
>>>> It
>>> consists of making a decision about whether a particular request
>>> should be allowed and enforcing that decision. Aside from schemes
>>> like permission bits and Access Control Lists (ACLs) the most common
>>> way access control is implemented is as code in a server or
>>> application which typically intertwines access control logic with
>>> business logic, User interface and other software. This makes it
>>> difficult to understand, modify, analyze or even locate the security
>>> policy. The primary challenge of Access Control is striking the right
>>> balance between powerful expression and intelligibility to human beings.
>>>> The OASIS XACML Standard exemplifies Attribute-Based Access Control
>>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from
>>> other components. The Policy Enforcement Point (PEP) must be located
>>> so as to be able to enforce the decision, typically near the
>>> resource. The PEP first asks the PDP if access should be allowed and
>>> provides data, in the form of Attributes, to be used as input to the
>>> policies held by the PDP.
>>>> In addition to responding permit or deny, XACML allows a policy to
>>> emit Obligations or Advice, which direct the PEP to do certain
>>> things, such logging the access or failure or promising to get rid of
>>> the data after 30 days.
>>>> Attributes are identified as being in a certain category which
>>> represents one element in the proposed access. For example attributes
>>> may be associated with the resource being accessed, the action being
>>> taken or the environment, .e.g. date/time. Attributes may also be
>>> associated with any or several types of Subjects, which represent the
>>> active parties to the access, such as the requester, intermediaries,
>>> the recipient (if different), the codebase, the machine executing the
>>> code.
>>>> Attributes may be provided by the PEP and usually at least a few
>>>> are,
>>> but Attributes may also added by other components of the system. It
>>> is also possible for a PDP to add attributes in the middle of policy
>>> evaluation. All of these obtain Attributes from the Policy
>>> Information Point (PIP).
>>>> The Policy Administration Point (PAP) creates policies and manages
>>> then through their life cycles and generally the entire infrastructure.
>>>> The XACML language is essentially a set of expressions which
>>>> evaluate
>>> to a Boolean. If true the policy is said to be applicable. The Policy
>>> contains permit or deny and may include Permissions and or Advice. If
>>> policies disagree we resolve the conflict with combining algorithms.
>>> XACML provides some standard ones and you can implement your own.
>>> Mostly they are common sense like drop non-applicable polices. A
>>> commonly used algorithm is default deny. Deny overrides permit.
>>>> Rationale
>>>>
>>>> Access Control may be the most basic security service, but for the
>>> most part it remains primitive in practice. While other services like
>>> message protection and authentication have seen many advances in
>>> recent years and decades, deployed access control systems are opaque,
>>> difficult to us and harder to manage. Most organizations claim that
>>> they have security policies, protect privacy and accurately report
>>> financial results, but in practice they have no real way of
>>> discovering whether their systems actually behave the way they are alleged to do.
>>>> Just the foreground problems relating to deploying practical ABAC
>>> systems make a formidable list. If only the PDP knows what the
>>> policies are, how do we make sure it gets the attributes it needs to
>>> evaluate policies? How can we name organize, register and dispatch
>>> Obligations and Advice, allowing handlers to be provided by the
>>> system and added by users? How can the XACML 3.0 feature of being
>>> able to create your own attribute categories best be supported by the
>>> infrastructure and utilized by users? What are the best ways to create and test policies?
>>> What tools will best help us analyze the effects of the policies in
>>> force?
>>>> However, new requirements are rapidly being introduced and need to
>>>> be
>>> met. Privacy requirements continue to increase in complexity and scope.
>>> Data which moves around, such as documents, need to be protected. We
>>> need secure ways to delegate authority without undermining the
>>> integrity of the access control system. New applications, business
>>> and social relationships are driving the need for new policy and
>>> delegation capabilities.
>>>> We believe that the way to meet these challenges is to get more
>>> people actively engaged in using what is currently available so they
>>> can understand its limitations and make it better. We need to make it
>>> far easier to get a basic access control infrastructure up and running.
>>> We need more people who are familiar with XACML the way many people
>>> are familiar with SQL. If as some people say, XACML is the assembly
>>> language of access control, we need the real world experience with it
>>> that will lead us to the useful abstractions that can be implemented
>>> in higher level languages and other tools.
>>>> Initial Goals
>>>>
>>>> Work is currently underway to extend the PEPAPI and increase its
>>> flexibility. Since it does not directly correspond to any standard
>>> the way AzAPI does, it is necessary to struggle with the issues of
>>> what to expose and what to hide from consumers of the API.
>>>> Other work in progress involves the architecture of Obligations and
>>> Advice. There is also an effort to develop a remote client which can
>>> easily be dropped into any Java environment and make decision
>>> requests of any commercial or open source XACML PDP.
>>>> The contribution of AT&T's framework creates a need to integrate the
>>> prior work with it. Most of the focus will be on AzAPI and the
>>> corresponding AT&T API, which do largely the same thing. The result
>>> is likely to be a synthesis, since each has features the other lacks.
>>> Then PEPAPI will need to be integrated with the new API. The AT&T PDP
>>> and PAP will be incorporated as is. There has been some parallel work
>>> done in the area of PIPs. Work will be required to understand how to
>>> proceed here.
>>>> Current Status
>>>>
>>>> Meritocracy
>>>>
>>>> The project was started by Prateek Mishra, Rich Levinson and Hal
>>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>>> Duanhua Tu and Ajith Nair contributed code both using and extending
>>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and
>>> Rich Levinson updated AzAPI to include all XACML 3.0 features. In
>>> 2014 Pam Dragosh and Chris Rath contributed the XACML infrastructure
>>> they had developed at AT&T.
>>>> During most of its history the project has been very small and has
>>> made decisions by informal consensus. Major design issues have been
>>> decided by open debate. Minor issues and experimental proposals have
>>> been openly welcomed. Several of the participants have a background
>>> in open consensus-based standards making.
>>>> In addition to the mailing list, the project has regular phone calls
>>> every other Thursday.
>>>> Community
>>>>
>>>> The original focus of the project was to attract developers of XACML
>>> products, either individuals or corporations, and to build alignment
>>> among vendors on a common API that could simplify technical
>>> integration for their customers. As OpenAz has matured, our community
>>> has grown to include application developers working to adopt and
>>> deploy XACML in their applications. So, for example, contributions
>>> reflect what individual developers have learned in vertical
>>> industries such as financial services, healthcare, and computing and
>>> communications services, and our APIs and internal component
>>> architecture have evolved to reflect a strong practical understanding
>>> of what it takes to deploy XACML applications in a large organization.
>>>> Core Developers
>>>>
>>>> The following developers have written most of the code to date.
>>>>
>>>> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>>>> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>>>> jpmchase dot com> Chris Rath <car at research dot att dot com>
>>> Duanhua
>>>> Tu <duanhua.tu at jpmchase dot com>
>>>>
>>>> The following people made other significant technical contributions.
>>>>
>>>> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>>>> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>>>> oracle dot com>
>>>>
>>>> Alignment
>>>>
>>>> It has always been a goal to make OpenAz an Apache project. The
>>> Apache license was used for all contributions. We believe the project
>>> has now reached a critical size in terms of developers, organizations
>>> and contributed code to make it appropriate to make a proposal to the
>>> Incubator.
>>>> Known Risks
>>>>
>>>> Orphaned Projects
>>>>
>>>> Given the small size of the project, there is a risk of the project
>>> being orphaned. There seems to be strong interest in the use of our
>>> tools, which should markedly increase with the contribution of the
>>> AT&T code. "Where can I get an open source PDP?" and "where can I get
>>> an open source policy editor?" are frequent questions on XACML
>>> mailing lists.
>>>> Inexperience with Open Source
>>>>
>>>> While few of the developers have extensive experience with open
>>> source, a number of us have long experience in standards making in
>>> open consensus-based environments. For example the XACML TC has
>>> operated since 2001 based on consensus building, with few, if any
>>> votes which were not unanimous. The main challenge to the project
>>> will be managing the process with more participants and a more formal process.
>>>> Homogeneous Developers
>>>>
>>>> Currently all the contributors are employees either of companies
>>> offering an XACML product or large end users deploying XACML
>>> technology for internal use. The positive aspect is that they are all
>>> highly experienced senior developers used to operating in a
>>> disciplined environment. The disadvantage is that the focus to date
>>> has mostly been problems that arise in large scale environments
>>> typified by the infrastructure of large corporations.
>>>> Reliance on Salaried Developers
>>>>
>>>> All current committers are salaried developers. However the
>>> organizations they work for have a long term commitment to the
>>> technology. We hope that in the Apache foundation we will be able to
>>> attract new developers to help us address the many fascinating
>>> unsolved technological problems associated with deploying ABAC.
>>>> Relationship with other Apache Projects
>>>>
>>>> As far as we can determine, no existing Apache project overlaps with
>>> OpenAz in its goals of the technology developed so far. However,
>>> beyond the immediate project goals there are many potential
>>> opportunities for integration with existing Apache projects. Shiro,
>>> Turbine and WSS4J are Java frameworks which could incorporate XACML
>>> as the policy language using OpenAz components. Manifold CF, Qpid and
>>> Archiva already have hooks to incorporate external access control systems.
>>>> An Excessive Fascination with the Apache Brand
>>>>
>>>> We hope that becoming an Apache project will not only attract new
>>> participants to OpenAz, but will draw attention to the neglected
>>> field of access control. As previously stated it has always been our
>>> goal to join Apache, the only question was when the time was ripe.
>>>> Documentation
>>>>
>>>> The OpenAz web site is:
>>>>
>>>> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>>>>
>>>> Java docs can be found here:
>>>>
>>>>
>>> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc
>>> /
>>>> index.html
>>>>
>>>> Initial Source
>>>>
>>>> The AzAPI, PEPAPI and other related code can be found on sourceforge:
>>>>
>>>> http://openaz.svn.sourceforge.net/viewvc/openaz/
>>>>
>>>> AT&T's framework can be found on github:
>>>>
>>>> https://github.com/att/XACML
>>>>
>>>> Source and Intellectual Property Submission Plan
>>>>
>>>> All the OpenAz code has been submitted under the Apache 2.0 license.
>>> The AT&T software is available under the MIT license. Over time the
>>> project will move to a single license.
>>>> External Dependencies
>>>>
>>>> There aren't any we are aware of.
>>>>
>>>> Cryptography
>>>>
>>>> OpenAz does not provide any cryptographic capabilities. The XACML
>>> Standard does specify some uses of cryptography directly, e.g.
>>> digital signatures over policies and others by implication, e.g.
>>> authentication via cryptography.
>>>> Required Resources
>>>>
>>>> Mailing lists
>>>>
>>>> The standard lists should be sufficient at the current time.The
>>> mailing list name will be openaz.
>>>> Git Directory
>>>>
>>>> We propose:
>>>> https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>>>>
>>>> Issue Tracking
>>>>
>>>> The project will use JIRA for issue tracking.
>>>>
>>>> Initial Committers
>>>>
>>>> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>>>> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>>>>
>>>> Affiliations
>>>>
>>>> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle.
>>>> David
>>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>>>> Sponsors
>>>>
>>>> Champion
>>>>
>>>> Paul Fremantle
>>>>
>>>> Nominated Mentors
>>>>
>>>> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>>>>
>>>> Sponsoring Entity
>>>>
>>>> The Sponsoring Entity will be the Incubator.
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: general-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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Thanks, Rich

Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

["RATH, CHRISTOPHER A (CHRISTOPHER A)" <ca...@research.att.com>]

+1.

--
Christopher A. Rath
Director Inventive Science – Intelligent Systems Research Department

-----Original Message-----
From: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Sent: Monday, January 05, 2015 10:28 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

+1.

I made some cosmetic changes to the list of committers and mentors. It should be clear now.

Hadrian


On 01/05/2015 02:04 PM, Hal Lockhart wrote:
> I added a comma and the word "and" to the Mentors section. The Mentors are:
>
> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>
> Do you see any other formatting errors?
>
> Hal
>
>> -----Original Message-----
>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>> Sent: Monday, January 05, 2015 1:24 PM
>> To: general@incubator.apache.org
>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>> into the Apache Incubator
>>
>> Hi!
>>
>> can you please fix the formatting issues? For example, I can't even
>> tell the exact list of mentors you're proposing.
>>
>> Thanks,
>> Roman.
>>
>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart
>> <ha...@oracle.com>
>> wrote:
>>> I call a vote to accept OpenAz as a new Incubator project.
>>>
>>> The proposal can be found here:
>>> https://wiki.apache.org/incubator/OpenAZProposal
>>>
>>> and is included below in this email.
>>>
>>> Voting will remain open until at least January 20, 2015 23:00 ET.
>>>
>>> Hal Lockhart
>>>
>>> --------------------------------------------------------------------
>>> -
>> -
>>> -----------------
>>>
>>> Abstract
>>>
>>> OpenAz is a project to create tools and libraries to enable the
>> development of Attribute-based Access Control (ABAC) Systems in a
>> variety of languages. In general the work is at least consistent with
>> or actually conformant to the OASIS XACML Standard.
>>> Proposal
>>>
>>> Generally the work falls into two categories: ready to use tools
>> which implement standardized or well understood components of an ABAC
>> system and design proposals and proof of concept code relating to
>> less well understood or experimental aspects of the problem.
>>> Much of the work to date has revolved around defining interfaces
>> enabling a PEP to request an access control decision from a PDP. The
>> XACML standard defines an abstract request format in xml and protocol
>> wire formats in xaml and json, but it does not specify programmatic
>> interfaces in any language. The standard says that the use of XML (or
>> JSON) is not required only the semantic equivalent.
>>> The first Interface, AzAPI is modeled closely on the XACML defined
>> interface, expressed in Java. One of the goals was to support calls
>> to both a PDP local to the same process and a PDP in a remote server.
>> AzAPI includes the interface, reference code to handle things like
>> the many supported datatypes in XACML and glue code to mate it to the
>> open source Sun XACML implementation.
>>> Because of the dependence on Sun XACML (which is XACML 2.0) the
>> interface was missing some XACML 3.0 features. More recently this was
>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>> pursuing this capability.
>>> A second, higher level interface, PEPAPI was also defined. PEPAPI is
>> more intended for application developers with little knowledge of
>> XACML. It allows Java objects which contain attribute information to
>> be passed in. Conversion methods, called mappers extract information
>> from the objects and present it in the format expected by XACML. Some
>> implementers have chosen to implement PEPAPI directly against their
>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>> which closely matches the Java one.
>>> Examples of more speculative work include: proposals for
>>> registration
>> and dispatch of Obligation and Advice handlers, a scheme called AMF
>> to tell PIPs how to retrieve attributes and PIP code to implement it,
>> discussion of PoC code to demonstrate the use of XACML policies to
>> drive OAuth interations and a proposal to use XACML policies to
>> express OAuth scope.
>>> AT&T has recently contributed their extensive XACML framework to the
>> project.
>>> The AT&T framework represents the entire XACML 3.0 object set as a
>> collection of Java interfaces and standard implementations of those
>> interfaces. The AT&T PDP engine is built on top of this framework and
>> represents a complete implementation of a XACML 3.0 PDP, including
>> all of the multi-decision profiles. In addition, the framework also
>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0
>> and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>> functionality, allowing application developers to simply annotate a
>> Java class to provide attributes for a request. The annotation
>> support removes the need for application developers to learn much of the API.
>>> The AT&T framework also includes interfaces and implementations to
>> standardize development of PIP engines that are used by the AT&T PDP
>> implementation, and can be used by other implementations built on top
>> of the AT&T framework. The framework also includes interfaces and
>> implementations for a PAP distributed cloud infrastructure of PDP
>> nodes that includes support for policy distribution and pip configurations.
>> This PAP infrastructure includes a web application administrative
>> console that contains a XACML 3.0 policy editor, attribute dictionary
>> support, and management of PDP RESTful node instances. In addition,
>> there are tools available for policy simulation.
>>> Background
>>>
>>> Access Control is in some ways the most basic IT Security service.
>>> It
>> consists of making a decision about whether a particular request
>> should be allowed and enforcing that decision. Aside from schemes
>> like permission bits and Access Control Lists (ACLs) the most common
>> way access control is implemented is as code in a server or
>> application which typically intertwines access control logic with
>> business logic, User interface and other software. This makes it
>> difficult to understand, modify, analyze or even locate the security
>> policy. The primary challenge of Access Control is striking the right
>> balance between powerful expression and intelligibility to human beings.
>>> The OASIS XACML Standard exemplifies Attribute-Based Access Control
>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from
>> other components. The Policy Enforcement Point (PEP) must be located
>> so as to be able to enforce the decision, typically near the
>> resource. The PEP first asks the PDP if access should be allowed and
>> provides data, in the form of Attributes, to be used as input to the
>> policies held by the PDP.
>>> In addition to responding permit or deny, XACML allows a policy to
>> emit Obligations or Advice, which direct the PEP to do certain
>> things, such logging the access or failure or promising to get rid of
>> the data after 30 days.
>>> Attributes are identified as being in a certain category which
>> represents one element in the proposed access. For example attributes
>> may be associated with the resource being accessed, the action being
>> taken or the environment, .e.g. date/time. Attributes may also be
>> associated with any or several types of Subjects, which represent the
>> active parties to the access, such as the requester, intermediaries,
>> the recipient (if different), the codebase, the machine executing the
>> code.
>>> Attributes may be provided by the PEP and usually at least a few
>>> are,
>> but Attributes may also added by other components of the system. It
>> is also possible for a PDP to add attributes in the middle of policy
>> evaluation. All of these obtain Attributes from the Policy
>> Information Point (PIP).
>>> The Policy Administration Point (PAP) creates policies and manages
>> then through their life cycles and generally the entire infrastructure.
>>> The XACML language is essentially a set of expressions which
>>> evaluate
>> to a Boolean. If true the policy is said to be applicable. The Policy
>> contains permit or deny and may include Permissions and or Advice. If
>> policies disagree we resolve the conflict with combining algorithms.
>> XACML provides some standard ones and you can implement your own.
>> Mostly they are common sense like drop non-applicable polices. A
>> commonly used algorithm is default deny. Deny overrides permit.
>>> Rationale
>>>
>>> Access Control may be the most basic security service, but for the
>> most part it remains primitive in practice. While other services like
>> message protection and authentication have seen many advances in
>> recent years and decades, deployed access control systems are opaque,
>> difficult to us and harder to manage. Most organizations claim that
>> they have security policies, protect privacy and accurately report
>> financial results, but in practice they have no real way of
>> discovering whether their systems actually behave the way they are alleged to do.
>>> Just the foreground problems relating to deploying practical ABAC
>> systems make a formidable list. If only the PDP knows what the
>> policies are, how do we make sure it gets the attributes it needs to
>> evaluate policies? How can we name organize, register and dispatch
>> Obligations and Advice, allowing handlers to be provided by the
>> system and added by users? How can the XACML 3.0 feature of being
>> able to create your own attribute categories best be supported by the
>> infrastructure and utilized by users? What are the best ways to create and test policies?
>> What tools will best help us analyze the effects of the policies in
>> force?
>>> However, new requirements are rapidly being introduced and need to
>>> be
>> met. Privacy requirements continue to increase in complexity and scope.
>> Data which moves around, such as documents, need to be protected. We
>> need secure ways to delegate authority without undermining the
>> integrity of the access control system. New applications, business
>> and social relationships are driving the need for new policy and
>> delegation capabilities.
>>> We believe that the way to meet these challenges is to get more
>> people actively engaged in using what is currently available so they
>> can understand its limitations and make it better. We need to make it
>> far easier to get a basic access control infrastructure up and running.
>> We need more people who are familiar with XACML the way many people
>> are familiar with SQL. If as some people say, XACML is the assembly
>> language of access control, we need the real world experience with it
>> that will lead us to the useful abstractions that can be implemented
>> in higher level languages and other tools.
>>> Initial Goals
>>>
>>> Work is currently underway to extend the PEPAPI and increase its
>> flexibility. Since it does not directly correspond to any standard
>> the way AzAPI does, it is necessary to struggle with the issues of
>> what to expose and what to hide from consumers of the API.
>>> Other work in progress involves the architecture of Obligations and
>> Advice. There is also an effort to develop a remote client which can
>> easily be dropped into any Java environment and make decision
>> requests of any commercial or open source XACML PDP.
>>> The contribution of AT&T's framework creates a need to integrate the
>> prior work with it. Most of the focus will be on AzAPI and the
>> corresponding AT&T API, which do largely the same thing. The result
>> is likely to be a synthesis, since each has features the other lacks.
>> Then PEPAPI will need to be integrated with the new API. The AT&T PDP
>> and PAP will be incorporated as is. There has been some parallel work
>> done in the area of PIPs. Work will be required to understand how to
>> proceed here.
>>> Current Status
>>>
>>> Meritocracy
>>>
>>> The project was started by Prateek Mishra, Rich Levinson and Hal
>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>> Duanhua Tu and Ajith Nair contributed code both using and extending
>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and
>> Rich Levinson updated AzAPI to include all XACML 3.0 features. In
>> 2014 Pam Dragosh and Chris Rath contributed the XACML infrastructure
>> they had developed at AT&T.
>>> During most of its history the project has been very small and has
>> made decisions by informal consensus. Major design issues have been
>> decided by open debate. Minor issues and experimental proposals have
>> been openly welcomed. Several of the participants have a background
>> in open consensus-based standards making.
>>> In addition to the mailing list, the project has regular phone calls
>> every other Thursday.
>>> Community
>>>
>>> The original focus of the project was to attract developers of XACML
>> products, either individuals or corporations, and to build alignment
>> among vendors on a common API that could simplify technical
>> integration for their customers. As OpenAz has matured, our community
>> has grown to include application developers working to adopt and
>> deploy XACML in their applications. So, for example, contributions
>> reflect what individual developers have learned in vertical
>> industries such as financial services, healthcare, and computing and
>> communications services, and our APIs and internal component
>> architecture have evolved to reflect a strong practical understanding
>> of what it takes to deploy XACML applications in a large organization.
>>> Core Developers
>>>
>>> The following developers have written most of the code to date.
>>>
>>> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>>> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>>> jpmchase dot com> Chris Rath <car at research dot att dot com>
>> Duanhua
>>> Tu <duanhua.tu at jpmchase dot com>
>>>
>>> The following people made other significant technical contributions.
>>>
>>> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>>> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>>> oracle dot com>
>>>
>>> Alignment
>>>
>>> It has always been a goal to make OpenAz an Apache project. The
>> Apache license was used for all contributions. We believe the project
>> has now reached a critical size in terms of developers, organizations
>> and contributed code to make it appropriate to make a proposal to the
>> Incubator.
>>> Known Risks
>>>
>>> Orphaned Projects
>>>
>>> Given the small size of the project, there is a risk of the project
>> being orphaned. There seems to be strong interest in the use of our
>> tools, which should markedly increase with the contribution of the
>> AT&T code. "Where can I get an open source PDP?" and "where can I get
>> an open source policy editor?" are frequent questions on XACML
>> mailing lists.
>>> Inexperience with Open Source
>>>
>>> While few of the developers have extensive experience with open
>> source, a number of us have long experience in standards making in
>> open consensus-based environments. For example the XACML TC has
>> operated since 2001 based on consensus building, with few, if any
>> votes which were not unanimous. The main challenge to the project
>> will be managing the process with more participants and a more formal process.
>>> Homogeneous Developers
>>>
>>> Currently all the contributors are employees either of companies
>> offering an XACML product or large end users deploying XACML
>> technology for internal use. The positive aspect is that they are all
>> highly experienced senior developers used to operating in a
>> disciplined environment. The disadvantage is that the focus to date
>> has mostly been problems that arise in large scale environments
>> typified by the infrastructure of large corporations.
>>> Reliance on Salaried Developers
>>>
>>> All current committers are salaried developers. However the
>> organizations they work for have a long term commitment to the
>> technology. We hope that in the Apache foundation we will be able to
>> attract new developers to help us address the many fascinating
>> unsolved technological problems associated with deploying ABAC.
>>> Relationship with other Apache Projects
>>>
>>> As far as we can determine, no existing Apache project overlaps with
>> OpenAz in its goals of the technology developed so far. However,
>> beyond the immediate project goals there are many potential
>> opportunities for integration with existing Apache projects. Shiro,
>> Turbine and WSS4J are Java frameworks which could incorporate XACML
>> as the policy language using OpenAz components. Manifold CF, Qpid and
>> Archiva already have hooks to incorporate external access control systems.
>>> An Excessive Fascination with the Apache Brand
>>>
>>> We hope that becoming an Apache project will not only attract new
>> participants to OpenAz, but will draw attention to the neglected
>> field of access control. As previously stated it has always been our
>> goal to join Apache, the only question was when the time was ripe.
>>> Documentation
>>>
>>> The OpenAz web site is:
>>>
>>> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>>>
>>> Java docs can be found here:
>>>
>>>
>> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc
>> /
>>> index.html
>>>
>>> Initial Source
>>>
>>> The AzAPI, PEPAPI and other related code can be found on sourceforge:
>>>
>>> http://openaz.svn.sourceforge.net/viewvc/openaz/
>>>
>>> AT&T's framework can be found on github:
>>>
>>> https://github.com/att/XACML
>>>
>>> Source and Intellectual Property Submission Plan
>>>
>>> All the OpenAz code has been submitted under the Apache 2.0 license.
>> The AT&T software is available under the MIT license. Over time the
>> project will move to a single license.
>>> External Dependencies
>>>
>>> There aren't any we are aware of.
>>>
>>> Cryptography
>>>
>>> OpenAz does not provide any cryptographic capabilities. The XACML
>> Standard does specify some uses of cryptography directly, e.g.
>> digital signatures over policies and others by implication, e.g.
>> authentication via cryptography.
>>> Required Resources
>>>
>>> Mailing lists
>>>
>>> The standard lists should be sufficient at the current time.The
>> mailing list name will be openaz.
>>> Git Directory
>>>
>>> We propose:
>>> https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>>>
>>> Issue Tracking
>>>
>>> The project will use JIRA for issue tracking.
>>>
>>> Initial Committers
>>>
>>> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>>> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>>>
>>> Affiliations
>>>
>>> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle.
>>> David
>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>>> Sponsors
>>>
>>> Champion
>>>
>>> Paul Fremantle
>>>
>>> Nominated Mentors
>>>
>>> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>>>
>>> Sponsoring Entity
>>>
>>> The Sponsoring Entity will be the Incubator.
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: general-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


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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

+1.

Colm.

On Tue, Jan 6, 2015 at 3:27 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:

> +1.
>
> I made some cosmetic changes to the list of committers and mentors. It
> should be clear now.
>
> Hadrian
>
>
>
> On 01/05/2015 02:04 PM, Hal Lockhart wrote:
>
>> I added a comma and the word "and" to the Mentors section. The Mentors
>> are:
>>
>> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>>
>> Do you see any other formatting errors?
>>
>> Hal
>>
>>  -----Original Message-----
>>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>>> Sent: Monday, January 05, 2015 1:24 PM
>>> To: general@incubator.apache.org
>>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>>> into the Apache Incubator
>>>
>>> Hi!
>>>
>>> can you please fix the formatting issues? For example, I can't even
>>> tell the exact list of mentors you're proposing.
>>>
>>> Thanks,
>>> Roman.
>>>
>>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com>
>>> wrote:
>>>
>>>> I call a vote to accept OpenAz as a new Incubator project.
>>>>
>>>> The proposal can be found here:
>>>> https://wiki.apache.org/incubator/OpenAZProposal
>>>>
>>>> and is included below in this email.
>>>>
>>>> Voting will remain open until at least January 20, 2015 23:00 ET.
>>>>
>>>> Hal Lockhart
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>> -
>>>
>>>> -----------------
>>>>
>>>> Abstract
>>>>
>>>> OpenAz is a project to create tools and libraries to enable the
>>>>
>>> development of Attribute-based Access Control (ABAC) Systems in a
>>> variety of languages. In general the work is at least consistent with
>>> or actually conformant to the OASIS XACML Standard.
>>>
>>>> Proposal
>>>>
>>>> Generally the work falls into two categories: ready to use tools
>>>>
>>> which implement standardized or well understood components of an ABAC
>>> system and design proposals and proof of concept code relating to less
>>> well understood or experimental aspects of the problem.
>>>
>>>> Much of the work to date has revolved around defining interfaces
>>>>
>>> enabling a PEP to request an access control decision from a PDP. The
>>> XACML standard defines an abstract request format in xml and protocol
>>> wire formats in xaml and json, but it does not specify programmatic
>>> interfaces in any language. The standard says that the use of XML (or
>>> JSON) is not required only the semantic equivalent.
>>>
>>>> The first Interface, AzAPI is modeled closely on the XACML defined
>>>>
>>> interface, expressed in Java. One of the goals was to support calls to
>>> both a PDP local to the same process and a PDP in a remote server.
>>> AzAPI includes the interface, reference code to handle things like the
>>> many supported datatypes in XACML and glue code to mate it to the open
>>> source Sun XACML implementation.
>>>
>>>> Because of the dependence on Sun XACML (which is XACML 2.0) the
>>>>
>>> interface was missing some XACML 3.0 features. More recently this was
>>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>>> pursuing this capability.
>>>
>>>> A second, higher level interface, PEPAPI was also defined. PEPAPI is
>>>>
>>> more intended for application developers with little knowledge of
>>> XACML. It allows Java objects which contain attribute information to be
>>> passed in. Conversion methods, called mappers extract information from
>>> the objects and present it in the format expected by XACML. Some
>>> implementers have chosen to implement PEPAPI directly against their
>>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>>> which closely matches the Java one.
>>>
>>>> Examples of more speculative work include: proposals for registration
>>>>
>>> and dispatch of Obligation and Advice handlers, a scheme called AMF to
>>> tell PIPs how to retrieve attributes and PIP code to implement it,
>>> discussion of PoC code to demonstrate the use of XACML policies to
>>> drive OAuth interations and a proposal to use XACML policies to express
>>> OAuth scope.
>>>
>>>> AT&T has recently contributed their extensive XACML framework to the
>>>>
>>> project.
>>>
>>>> The AT&T framework represents the entire XACML 3.0 object set as a
>>>>
>>> collection of Java interfaces and standard implementations of those
>>> interfaces. The AT&T PDP engine is built on top of this framework and
>>> represents a complete implementation of a XACML 3.0 PDP, including all
>>> of the multi-decision profiles. In addition, the framework also
>>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
>>> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>>> functionality, allowing application developers to simply annotate a
>>> Java class to provide attributes for a request. The annotation support
>>> removes the need for application developers to learn much of the API.
>>>
>>>> The AT&T framework also includes interfaces and implementations to
>>>>
>>> standardize development of PIP engines that are used by the AT&T PDP
>>> implementation, and can be used by other implementations built on top
>>> of the AT&T framework. The framework also includes interfaces and
>>> implementations for a PAP distributed cloud infrastructure of PDP nodes
>>> that includes support for policy distribution and pip configurations.
>>> This PAP infrastructure includes a web application administrative
>>> console that contains a XACML 3.0 policy editor, attribute dictionary
>>> support, and management of PDP RESTful node instances. In addition,
>>> there are tools available for policy simulation.
>>>
>>>> Background
>>>>
>>>> Access Control is in some ways the most basic IT Security service. It
>>>>
>>> consists of making a decision about whether a particular request should
>>> be allowed and enforcing that decision. Aside from schemes like
>>> permission bits and Access Control Lists (ACLs) the most common way
>>> access control is implemented is as code in a server or application
>>> which typically intertwines access control logic with business logic,
>>> User interface and other software. This makes it difficult to
>>> understand, modify, analyze or even locate the security policy. The
>>> primary challenge of Access Control is striking the right balance
>>> between powerful expression and intelligibility to human beings.
>>>
>>>> The OASIS XACML Standard exemplifies Attribute-Based Access Control
>>>>
>>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
>>> components. The Policy Enforcement Point (PEP) must be located so as to
>>> be able to enforce the decision, typically near the resource. The PEP
>>> first asks the PDP if access should be allowed and provides data, in
>>> the form of Attributes, to be used as input to the policies held by the
>>> PDP.
>>>
>>>> In addition to responding permit or deny, XACML allows a policy to
>>>>
>>> emit Obligations or Advice, which direct the PEP to do certain things,
>>> such logging the access or failure or promising to get rid of the data
>>> after 30 days.
>>>
>>>> Attributes are identified as being in a certain category which
>>>>
>>> represents one element in the proposed access. For example attributes
>>> may be associated with the resource being accessed, the action being
>>> taken or the environment, .e.g. date/time. Attributes may also be
>>> associated with any or several types of Subjects, which represent the
>>> active parties to the access, such as the requester, intermediaries,
>>> the recipient (if different), the codebase, the machine executing the
>>> code.
>>>
>>>> Attributes may be provided by the PEP and usually at least a few are,
>>>>
>>> but Attributes may also added by other components of the system. It is
>>> also possible for a PDP to add attributes in the middle of policy
>>> evaluation. All of these obtain Attributes from the Policy Information
>>> Point (PIP).
>>>
>>>> The Policy Administration Point (PAP) creates policies and manages
>>>>
>>> then through their life cycles and generally the entire infrastructure.
>>>
>>>> The XACML language is essentially a set of expressions which evaluate
>>>>
>>> to a Boolean. If true the policy is said to be applicable. The Policy
>>> contains permit or deny and may include Permissions and or Advice. If
>>> policies disagree we resolve the conflict with combining algorithms.
>>> XACML provides some standard ones and you can implement your own.
>>> Mostly they are common sense like drop non-applicable polices. A
>>> commonly used algorithm is default deny. Deny overrides permit.
>>>
>>>> Rationale
>>>>
>>>> Access Control may be the most basic security service, but for the
>>>>
>>> most part it remains primitive in practice. While other services like
>>> message protection and authentication have seen many advances in recent
>>> years and decades, deployed access control systems are opaque,
>>> difficult to us and harder to manage. Most organizations claim that
>>> they have security policies, protect privacy and accurately report
>>> financial results, but in practice they have no real way of discovering
>>> whether their systems actually behave the way they are alleged to do.
>>>
>>>> Just the foreground problems relating to deploying practical ABAC
>>>>
>>> systems make a formidable list. If only the PDP knows what the policies
>>> are, how do we make sure it gets the attributes it needs to evaluate
>>> policies? How can we name organize, register and dispatch Obligations
>>> and Advice, allowing handlers to be provided by the system and added by
>>> users? How can the XACML 3.0 feature of being able to create your own
>>> attribute categories best be supported by the infrastructure and
>>> utilized by users? What are the best ways to create and test policies?
>>> What tools will best help us analyze the effects of the policies in
>>> force?
>>>
>>>> However, new requirements are rapidly being introduced and need to be
>>>>
>>> met. Privacy requirements continue to increase in complexity and scope.
>>> Data which moves around, such as documents, need to be protected. We
>>> need secure ways to delegate authority without undermining the
>>> integrity of the access control system. New applications, business and
>>> social relationships are driving the need for new policy and delegation
>>> capabilities.
>>>
>>>> We believe that the way to meet these challenges is to get more
>>>>
>>> people actively engaged in using what is currently available so they
>>> can understand its limitations and make it better. We need to make it
>>> far easier to get a basic access control infrastructure up and running.
>>> We need more people who are familiar with XACML the way many people are
>>> familiar with SQL. If as some people say, XACML is the assembly
>>> language of access control, we need the real world experience with it
>>> that will lead us to the useful abstractions that can be implemented in
>>> higher level languages and other tools.
>>>
>>>> Initial Goals
>>>>
>>>> Work is currently underway to extend the PEPAPI and increase its
>>>>
>>> flexibility. Since it does not directly correspond to any standard the
>>> way AzAPI does, it is necessary to struggle with the issues of what to
>>> expose and what to hide from consumers of the API.
>>>
>>>> Other work in progress involves the architecture of Obligations and
>>>>
>>> Advice. There is also an effort to develop a remote client which can
>>> easily be dropped into any Java environment and make decision requests
>>> of any commercial or open source XACML PDP.
>>>
>>>> The contribution of AT&T's framework creates a need to integrate the
>>>>
>>> prior work with it. Most of the focus will be on AzAPI and the
>>> corresponding AT&T API, which do largely the same thing. The result is
>>> likely to be a synthesis, since each has features the other lacks. Then
>>> PEPAPI will need to be integrated with the new API. The AT&T PDP and
>>> PAP will be incorporated as is. There has been some parallel work done
>>> in the area of PIPs. Work will be required to understand how to proceed
>>> here.
>>>
>>>> Current Status
>>>>
>>>> Meritocracy
>>>>
>>>> The project was started by Prateek Mishra, Rich Levinson and Hal
>>>>
>>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>>> Duanhua Tu and Ajith Nair contributed code both using and extending
>>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
>>> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
>>> Dragosh and Chris Rath contributed the XACML infrastructure they had
>>> developed at AT&T.
>>>
>>>> During most of its history the project has been very small and has
>>>>
>>> made decisions by informal consensus. Major design issues have been
>>> decided by open debate. Minor issues and experimental proposals have
>>> been openly welcomed. Several of the participants have a background in
>>> open consensus-based standards making.
>>>
>>>> In addition to the mailing list, the project has regular phone calls
>>>>
>>> every other Thursday.
>>>
>>>> Community
>>>>
>>>> The original focus of the project was to attract developers of XACML
>>>>
>>> products, either individuals or corporations, and to build alignment
>>> among vendors on a common API that could simplify technical integration
>>> for their customers. As OpenAz has matured, our community has grown to
>>> include application developers working to adopt and deploy XACML in
>>> their applications. So, for example, contributions reflect what
>>> individual developers have learned in vertical industries such as
>>> financial services, healthcare, and computing and communications
>>> services, and our APIs and internal component architecture have evolved
>>> to reflect a strong practical understanding of what it takes to deploy
>>> XACML applications in a large organization.
>>>
>>>> Core Developers
>>>>
>>>> The following developers have written most of the code to date.
>>>>
>>>> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>>>> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>>>> jpmchase dot com> Chris Rath <car at research dot att dot com>
>>>>
>>> Duanhua
>>>
>>>> Tu <duanhua.tu at jpmchase dot com>
>>>>
>>>> The following people made other significant technical contributions.
>>>>
>>>> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>>>> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>>>> oracle dot com>
>>>>
>>>> Alignment
>>>>
>>>> It has always been a goal to make OpenAz an Apache project. The
>>>>
>>> Apache license was used for all contributions. We believe the project
>>> has now reached a critical size in terms of developers, organizations
>>> and contributed code to make it appropriate to make a proposal to the
>>> Incubator.
>>>
>>>> Known Risks
>>>>
>>>> Orphaned Projects
>>>>
>>>> Given the small size of the project, there is a risk of the project
>>>>
>>> being orphaned. There seems to be strong interest in the use of our
>>> tools, which should markedly increase with the contribution of the AT&T
>>> code. "Where can I get an open source PDP?" and "where can I get an
>>> open source policy editor?" are frequent questions on XACML mailing
>>> lists.
>>>
>>>> Inexperience with Open Source
>>>>
>>>> While few of the developers have extensive experience with open
>>>>
>>> source, a number of us have long experience in standards making in open
>>> consensus-based environments. For example the XACML TC has operated
>>> since 2001 based on consensus building, with few, if any votes which
>>> were not unanimous. The main challenge to the project will be managing
>>> the process with more participants and a more formal process.
>>>
>>>> Homogeneous Developers
>>>>
>>>> Currently all the contributors are employees either of companies
>>>>
>>> offering an XACML product or large end users deploying XACML technology
>>> for internal use. The positive aspect is that they are all highly
>>> experienced senior developers used to operating in a disciplined
>>> environment. The disadvantage is that the focus to date has mostly been
>>> problems that arise in large scale environments typified by the
>>> infrastructure of large corporations.
>>>
>>>> Reliance on Salaried Developers
>>>>
>>>> All current committers are salaried developers. However the
>>>>
>>> organizations they work for have a long term commitment to the
>>> technology. We hope that in the Apache foundation we will be able to
>>> attract new developers to help us address the many fascinating unsolved
>>> technological problems associated with deploying ABAC.
>>>
>>>> Relationship with other Apache Projects
>>>>
>>>> As far as we can determine, no existing Apache project overlaps with
>>>>
>>> OpenAz in its goals of the technology developed so far. However, beyond
>>> the immediate project goals there are many potential opportunities for
>>> integration with existing Apache projects. Shiro, Turbine and WSS4J are
>>> Java frameworks which could incorporate XACML as the policy language
>>> using OpenAz components. Manifold CF, Qpid and Archiva already have
>>> hooks to incorporate external access control systems.
>>>
>>>> An Excessive Fascination with the Apache Brand
>>>>
>>>> We hope that becoming an Apache project will not only attract new
>>>>
>>> participants to OpenAz, but will draw attention to the neglected field
>>> of access control. As previously stated it has always been our goal to
>>> join Apache, the only question was when the time was ripe.
>>>
>>>> Documentation
>>>>
>>>> The OpenAz web site is:
>>>>
>>>> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>>>>
>>>> Java docs can be found here:
>>>>
>>>>
>>>>  http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
>>>
>>>> index.html
>>>>
>>>> Initial Source
>>>>
>>>> The AzAPI, PEPAPI and other related code can be found on sourceforge:
>>>>
>>>> http://openaz.svn.sourceforge.net/viewvc/openaz/
>>>>
>>>> AT&T's framework can be found on github:
>>>>
>>>> https://github.com/att/XACML
>>>>
>>>> Source and Intellectual Property Submission Plan
>>>>
>>>> All the OpenAz code has been submitted under the Apache 2.0 license.
>>>>
>>> The AT&T software is available under the MIT license. Over time the
>>> project will move to a single license.
>>>
>>>> External Dependencies
>>>>
>>>> There aren't any we are aware of.
>>>>
>>>> Cryptography
>>>>
>>>> OpenAz does not provide any cryptographic capabilities. The XACML
>>>>
>>> Standard does specify some uses of cryptography directly, e.g. digital
>>> signatures over policies and others by implication, e.g. authentication
>>> via cryptography.
>>>
>>>> Required Resources
>>>>
>>>> Mailing lists
>>>>
>>>> The standard lists should be sufficient at the current time.The
>>>>
>>> mailing list name will be openaz.
>>>
>>>> Git Directory
>>>>
>>>> We propose:
>>>> https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>>>>
>>>> Issue Tracking
>>>>
>>>> The project will use JIRA for issue tracking.
>>>>
>>>> Initial Committers
>>>>
>>>> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>>>> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>>>>
>>>> Affiliations
>>>>
>>>> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
>>>>
>>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>>>
>>>> Sponsors
>>>>
>>>> Champion
>>>>
>>>> Paul Fremantle
>>>>
>>>> Nominated Mentors
>>>>
>>>> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>>>>
>>>> Sponsoring Entity
>>>>
>>>> The Sponsoring Entity will be the Incubator.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-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
>
>


-- 
Colm O hEigeartaigh

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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Hadrian Zbarcea <hz...@gmail.com>]

+1.

I made some cosmetic changes to the list of committers and mentors. It 
should be clear now.

Hadrian


On 01/05/2015 02:04 PM, Hal Lockhart wrote:
> I added a comma and the word "and" to the Mentors section. The Mentors are:
>
> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>
> Do you see any other formatting errors?
>
> Hal
>
>> -----Original Message-----
>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>> Sent: Monday, January 05, 2015 1:24 PM
>> To: general@incubator.apache.org
>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>> into the Apache Incubator
>>
>> Hi!
>>
>> can you please fix the formatting issues? For example, I can't even
>> tell the exact list of mentors you're proposing.
>>
>> Thanks,
>> Roman.
>>
>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com>
>> wrote:
>>> I call a vote to accept OpenAz as a new Incubator project.
>>>
>>> The proposal can be found here:
>>> https://wiki.apache.org/incubator/OpenAZProposal
>>>
>>> and is included below in this email.
>>>
>>> Voting will remain open until at least January 20, 2015 23:00 ET.
>>>
>>> Hal Lockhart
>>>
>>> ---------------------------------------------------------------------
>> -
>>> -----------------
>>>
>>> Abstract
>>>
>>> OpenAz is a project to create tools and libraries to enable the
>> development of Attribute-based Access Control (ABAC) Systems in a
>> variety of languages. In general the work is at least consistent with
>> or actually conformant to the OASIS XACML Standard.
>>> Proposal
>>>
>>> Generally the work falls into two categories: ready to use tools
>> which implement standardized or well understood components of an ABAC
>> system and design proposals and proof of concept code relating to less
>> well understood or experimental aspects of the problem.
>>> Much of the work to date has revolved around defining interfaces
>> enabling a PEP to request an access control decision from a PDP. The
>> XACML standard defines an abstract request format in xml and protocol
>> wire formats in xaml and json, but it does not specify programmatic
>> interfaces in any language. The standard says that the use of XML (or
>> JSON) is not required only the semantic equivalent.
>>> The first Interface, AzAPI is modeled closely on the XACML defined
>> interface, expressed in Java. One of the goals was to support calls to
>> both a PDP local to the same process and a PDP in a remote server.
>> AzAPI includes the interface, reference code to handle things like the
>> many supported datatypes in XACML and glue code to mate it to the open
>> source Sun XACML implementation.
>>> Because of the dependence on Sun XACML (which is XACML 2.0) the
>> interface was missing some XACML 3.0 features. More recently this was
>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>> pursuing this capability.
>>> A second, higher level interface, PEPAPI was also defined. PEPAPI is
>> more intended for application developers with little knowledge of
>> XACML. It allows Java objects which contain attribute information to be
>> passed in. Conversion methods, called mappers extract information from
>> the objects and present it in the format expected by XACML. Some
>> implementers have chosen to implement PEPAPI directly against their
>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>> which closely matches the Java one.
>>> Examples of more speculative work include: proposals for registration
>> and dispatch of Obligation and Advice handlers, a scheme called AMF to
>> tell PIPs how to retrieve attributes and PIP code to implement it,
>> discussion of PoC code to demonstrate the use of XACML policies to
>> drive OAuth interations and a proposal to use XACML policies to express
>> OAuth scope.
>>> AT&T has recently contributed their extensive XACML framework to the
>> project.
>>> The AT&T framework represents the entire XACML 3.0 object set as a
>> collection of Java interfaces and standard implementations of those
>> interfaces. The AT&T PDP engine is built on top of this framework and
>> represents a complete implementation of a XACML 3.0 PDP, including all
>> of the multi-decision profiles. In addition, the framework also
>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
>> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>> functionality, allowing application developers to simply annotate a
>> Java class to provide attributes for a request. The annotation support
>> removes the need for application developers to learn much of the API.
>>> The AT&T framework also includes interfaces and implementations to
>> standardize development of PIP engines that are used by the AT&T PDP
>> implementation, and can be used by other implementations built on top
>> of the AT&T framework. The framework also includes interfaces and
>> implementations for a PAP distributed cloud infrastructure of PDP nodes
>> that includes support for policy distribution and pip configurations.
>> This PAP infrastructure includes a web application administrative
>> console that contains a XACML 3.0 policy editor, attribute dictionary
>> support, and management of PDP RESTful node instances. In addition,
>> there are tools available for policy simulation.
>>> Background
>>>
>>> Access Control is in some ways the most basic IT Security service. It
>> consists of making a decision about whether a particular request should
>> be allowed and enforcing that decision. Aside from schemes like
>> permission bits and Access Control Lists (ACLs) the most common way
>> access control is implemented is as code in a server or application
>> which typically intertwines access control logic with business logic,
>> User interface and other software. This makes it difficult to
>> understand, modify, analyze or even locate the security policy. The
>> primary challenge of Access Control is striking the right balance
>> between powerful expression and intelligibility to human beings.
>>> The OASIS XACML Standard exemplifies Attribute-Based Access Control
>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
>> components. The Policy Enforcement Point (PEP) must be located so as to
>> be able to enforce the decision, typically near the resource. The PEP
>> first asks the PDP if access should be allowed and provides data, in
>> the form of Attributes, to be used as input to the policies held by the
>> PDP.
>>> In addition to responding permit or deny, XACML allows a policy to
>> emit Obligations or Advice, which direct the PEP to do certain things,
>> such logging the access or failure or promising to get rid of the data
>> after 30 days.
>>> Attributes are identified as being in a certain category which
>> represents one element in the proposed access. For example attributes
>> may be associated with the resource being accessed, the action being
>> taken or the environment, .e.g. date/time. Attributes may also be
>> associated with any or several types of Subjects, which represent the
>> active parties to the access, such as the requester, intermediaries,
>> the recipient (if different), the codebase, the machine executing the
>> code.
>>> Attributes may be provided by the PEP and usually at least a few are,
>> but Attributes may also added by other components of the system. It is
>> also possible for a PDP to add attributes in the middle of policy
>> evaluation. All of these obtain Attributes from the Policy Information
>> Point (PIP).
>>> The Policy Administration Point (PAP) creates policies and manages
>> then through their life cycles and generally the entire infrastructure.
>>> The XACML language is essentially a set of expressions which evaluate
>> to a Boolean. If true the policy is said to be applicable. The Policy
>> contains permit or deny and may include Permissions and or Advice. If
>> policies disagree we resolve the conflict with combining algorithms.
>> XACML provides some standard ones and you can implement your own.
>> Mostly they are common sense like drop non-applicable polices. A
>> commonly used algorithm is default deny. Deny overrides permit.
>>> Rationale
>>>
>>> Access Control may be the most basic security service, but for the
>> most part it remains primitive in practice. While other services like
>> message protection and authentication have seen many advances in recent
>> years and decades, deployed access control systems are opaque,
>> difficult to us and harder to manage. Most organizations claim that
>> they have security policies, protect privacy and accurately report
>> financial results, but in practice they have no real way of discovering
>> whether their systems actually behave the way they are alleged to do.
>>> Just the foreground problems relating to deploying practical ABAC
>> systems make a formidable list. If only the PDP knows what the policies
>> are, how do we make sure it gets the attributes it needs to evaluate
>> policies? How can we name organize, register and dispatch Obligations
>> and Advice, allowing handlers to be provided by the system and added by
>> users? How can the XACML 3.0 feature of being able to create your own
>> attribute categories best be supported by the infrastructure and
>> utilized by users? What are the best ways to create and test policies?
>> What tools will best help us analyze the effects of the policies in
>> force?
>>> However, new requirements are rapidly being introduced and need to be
>> met. Privacy requirements continue to increase in complexity and scope.
>> Data which moves around, such as documents, need to be protected. We
>> need secure ways to delegate authority without undermining the
>> integrity of the access control system. New applications, business and
>> social relationships are driving the need for new policy and delegation
>> capabilities.
>>> We believe that the way to meet these challenges is to get more
>> people actively engaged in using what is currently available so they
>> can understand its limitations and make it better. We need to make it
>> far easier to get a basic access control infrastructure up and running.
>> We need more people who are familiar with XACML the way many people are
>> familiar with SQL. If as some people say, XACML is the assembly
>> language of access control, we need the real world experience with it
>> that will lead us to the useful abstractions that can be implemented in
>> higher level languages and other tools.
>>> Initial Goals
>>>
>>> Work is currently underway to extend the PEPAPI and increase its
>> flexibility. Since it does not directly correspond to any standard the
>> way AzAPI does, it is necessary to struggle with the issues of what to
>> expose and what to hide from consumers of the API.
>>> Other work in progress involves the architecture of Obligations and
>> Advice. There is also an effort to develop a remote client which can
>> easily be dropped into any Java environment and make decision requests
>> of any commercial or open source XACML PDP.
>>> The contribution of AT&T's framework creates a need to integrate the
>> prior work with it. Most of the focus will be on AzAPI and the
>> corresponding AT&T API, which do largely the same thing. The result is
>> likely to be a synthesis, since each has features the other lacks. Then
>> PEPAPI will need to be integrated with the new API. The AT&T PDP and
>> PAP will be incorporated as is. There has been some parallel work done
>> in the area of PIPs. Work will be required to understand how to proceed
>> here.
>>> Current Status
>>>
>>> Meritocracy
>>>
>>> The project was started by Prateek Mishra, Rich Levinson and Hal
>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>> Duanhua Tu and Ajith Nair contributed code both using and extending
>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
>> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
>> Dragosh and Chris Rath contributed the XACML infrastructure they had
>> developed at AT&T.
>>> During most of its history the project has been very small and has
>> made decisions by informal consensus. Major design issues have been
>> decided by open debate. Minor issues and experimental proposals have
>> been openly welcomed. Several of the participants have a background in
>> open consensus-based standards making.
>>> In addition to the mailing list, the project has regular phone calls
>> every other Thursday.
>>> Community
>>>
>>> The original focus of the project was to attract developers of XACML
>> products, either individuals or corporations, and to build alignment
>> among vendors on a common API that could simplify technical integration
>> for their customers. As OpenAz has matured, our community has grown to
>> include application developers working to adopt and deploy XACML in
>> their applications. So, for example, contributions reflect what
>> individual developers have learned in vertical industries such as
>> financial services, healthcare, and computing and communications
>> services, and our APIs and internal component architecture have evolved
>> to reflect a strong practical understanding of what it takes to deploy
>> XACML applications in a large organization.
>>> Core Developers
>>>
>>> The following developers have written most of the code to date.
>>>
>>> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>>> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>>> jpmchase dot com> Chris Rath <car at research dot att dot com>
>> Duanhua
>>> Tu <duanhua.tu at jpmchase dot com>
>>>
>>> The following people made other significant technical contributions.
>>>
>>> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>>> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>>> oracle dot com>
>>>
>>> Alignment
>>>
>>> It has always been a goal to make OpenAz an Apache project. The
>> Apache license was used for all contributions. We believe the project
>> has now reached a critical size in terms of developers, organizations
>> and contributed code to make it appropriate to make a proposal to the
>> Incubator.
>>> Known Risks
>>>
>>> Orphaned Projects
>>>
>>> Given the small size of the project, there is a risk of the project
>> being orphaned. There seems to be strong interest in the use of our
>> tools, which should markedly increase with the contribution of the AT&T
>> code. "Where can I get an open source PDP?" and "where can I get an
>> open source policy editor?" are frequent questions on XACML mailing
>> lists.
>>> Inexperience with Open Source
>>>
>>> While few of the developers have extensive experience with open
>> source, a number of us have long experience in standards making in open
>> consensus-based environments. For example the XACML TC has operated
>> since 2001 based on consensus building, with few, if any votes which
>> were not unanimous. The main challenge to the project will be managing
>> the process with more participants and a more formal process.
>>> Homogeneous Developers
>>>
>>> Currently all the contributors are employees either of companies
>> offering an XACML product or large end users deploying XACML technology
>> for internal use. The positive aspect is that they are all highly
>> experienced senior developers used to operating in a disciplined
>> environment. The disadvantage is that the focus to date has mostly been
>> problems that arise in large scale environments typified by the
>> infrastructure of large corporations.
>>> Reliance on Salaried Developers
>>>
>>> All current committers are salaried developers. However the
>> organizations they work for have a long term commitment to the
>> technology. We hope that in the Apache foundation we will be able to
>> attract new developers to help us address the many fascinating unsolved
>> technological problems associated with deploying ABAC.
>>> Relationship with other Apache Projects
>>>
>>> As far as we can determine, no existing Apache project overlaps with
>> OpenAz in its goals of the technology developed so far. However, beyond
>> the immediate project goals there are many potential opportunities for
>> integration with existing Apache projects. Shiro, Turbine and WSS4J are
>> Java frameworks which could incorporate XACML as the policy language
>> using OpenAz components. Manifold CF, Qpid and Archiva already have
>> hooks to incorporate external access control systems.
>>> An Excessive Fascination with the Apache Brand
>>>
>>> We hope that becoming an Apache project will not only attract new
>> participants to OpenAz, but will draw attention to the neglected field
>> of access control. As previously stated it has always been our goal to
>> join Apache, the only question was when the time was ripe.
>>> Documentation
>>>
>>> The OpenAz web site is:
>>>
>>> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>>>
>>> Java docs can be found here:
>>>
>>>
>> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
>>> index.html
>>>
>>> Initial Source
>>>
>>> The AzAPI, PEPAPI and other related code can be found on sourceforge:
>>>
>>> http://openaz.svn.sourceforge.net/viewvc/openaz/
>>>
>>> AT&T's framework can be found on github:
>>>
>>> https://github.com/att/XACML
>>>
>>> Source and Intellectual Property Submission Plan
>>>
>>> All the OpenAz code has been submitted under the Apache 2.0 license.
>> The AT&T software is available under the MIT license. Over time the
>> project will move to a single license.
>>> External Dependencies
>>>
>>> There aren't any we are aware of.
>>>
>>> Cryptography
>>>
>>> OpenAz does not provide any cryptographic capabilities. The XACML
>> Standard does specify some uses of cryptography directly, e.g. digital
>> signatures over policies and others by implication, e.g. authentication
>> via cryptography.
>>> Required Resources
>>>
>>> Mailing lists
>>>
>>> The standard lists should be sufficient at the current time.The
>> mailing list name will be openaz.
>>> Git Directory
>>>
>>> We propose:
>>> https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>>>
>>> Issue Tracking
>>>
>>> The project will use JIRA for issue tracking.
>>>
>>> Initial Committers
>>>
>>> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>>> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>>>
>>> Affiliations
>>>
>>> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>>> Sponsors
>>>
>>> Champion
>>>
>>> Paul Fremantle
>>>
>>> Nominated Mentors
>>>
>>> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>>>
>>> Sponsoring Entity
>>>
>>> The Sponsoring Entity will be the Incubator.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[David Laurance <da...@gmail.com>]

+1 
> On Jan 13, 2015, at 4:58 AM, Paul Fremantle <pz...@gmail.com> wrote:
> 
> +1 from me!
> 
> Paul
> 
> On Thu, Jan 8, 2015 at 6:10 PM, Dilli Arumugam <da...@hortonworks.com>
> wrote:
> 
>> +1
>> 
>> On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) <
>> pdragosh@research.att.com> wrote:
>> 
>>> +1
>>> 
>>> 
>>> Pam
>>> 
>>> Pamela L. Dragosh
>>> PMTS ­ Research
>>> One AT&T Way
>>> 4D-170P
>>> Bedminster, NJ 07921
>>> 908-901-2120 - Office
>>> pdragosh@research.att.com
>>> 
>>> 
>>> 
>>> On 1/5/15, 2:04 PM, "Hal Lockhart" <ha...@oracle.com> wrote:
>>> 
>>>> I added a comma and the word "and" to the Mentors section. The Mentors
>>>> are:
>>>> 
>>>> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>>>> 
>>>> Do you see any other formatting errors?
>>>> 
>>>> Hal
>>>> 
>>>>> -----Original Message-----
>>>>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>>>>> Sent: Monday, January 05, 2015 1:24 PM
>>>>> To: general@incubator.apache.org
>>>>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>>>>> into the Apache Incubator
>>>>> 
>>>>> Hi!
>>>>> 
>>>>> can you please fix the formatting issues? For example, I can't even
>>>>> tell the exact list of mentors you're proposing.
>>>>> 
>>>>> Thanks,
>>>>> Roman.
>>>>> 
>>>>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <
>> hal.lockhart@oracle.com>
>>>>> wrote:
>>>>>> I call a vote to accept OpenAz as a new Incubator project.
>>>>>> 
>>>>>> The proposal can be found here:
>>>>>> https://wiki.apache.org/incubator/OpenAZProposal
>>>>>> 
>>>>>> and is included below in this email.
>>>>>> 
>>>>>> Voting will remain open until at least January 20, 2015 23:00 ET.
>>>>>> 
>>>>>> Hal Lockhart
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>> -
>>>>>> -----------------
>>>>>> 
>>>>>> Abstract
>>>>>> 
>>>>>> OpenAz is a project to create tools and libraries to enable the
>>>>> development of Attribute-based Access Control (ABAC) Systems in a
>>>>> variety of languages. In general the work is at least consistent with
>>>>> or actually conformant to the OASIS XACML Standard.
>>>>>> 
>>>>>> Proposal
>>>>>> 
>>>>>> Generally the work falls into two categories: ready to use tools
>>>>> which implement standardized or well understood components of an ABAC
>>>>> system and design proposals and proof of concept code relating to less
>>>>> well understood or experimental aspects of the problem.
>>>>>> 
>>>>>> Much of the work to date has revolved around defining interfaces
>>>>> enabling a PEP to request an access control decision from a PDP. The
>>>>> XACML standard defines an abstract request format in xml and protocol
>>>>> wire formats in xaml and json, but it does not specify programmatic
>>>>> interfaces in any language. The standard says that the use of XML (or
>>>>> JSON) is not required only the semantic equivalent.
>>>>>> 
>>>>>> The first Interface, AzAPI is modeled closely on the XACML defined
>>>>> interface, expressed in Java. One of the goals was to support calls to
>>>>> both a PDP local to the same process and a PDP in a remote server.
>>>>> AzAPI includes the interface, reference code to handle things like the
>>>>> many supported datatypes in XACML and glue code to mate it to the open
>>>>> source Sun XACML implementation.
>>>>>> 
>>>>>> Because of the dependence on Sun XACML (which is XACML 2.0) the
>>>>> interface was missing some XACML 3.0 features. More recently this was
>>>>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>>>>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>>>>> pursuing this capability.
>>>>>> 
>>>>>> A second, higher level interface, PEPAPI was also defined. PEPAPI is
>>>>> more intended for application developers with little knowledge of
>>>>> XACML. It allows Java objects which contain attribute information to
>> be
>>>>> passed in. Conversion methods, called mappers extract information from
>>>>> the objects and present it in the format expected by XACML. Some
>>>>> implementers have chosen to implement PEPAPI directly against their
>>>>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>>>>> which closely matches the Java one.
>>>>>> 
>>>>>> Examples of more speculative work include: proposals for
>> registration
>>>>> and dispatch of Obligation and Advice handlers, a scheme called AMF to
>>>>> tell PIPs how to retrieve attributes and PIP code to implement it,
>>>>> discussion of PoC code to demonstrate the use of XACML policies to
>>>>> drive OAuth interations and a proposal to use XACML policies to
>> express
>>>>> OAuth scope.
>>>>>> 
>>>>>> AT&T has recently contributed their extensive XACML framework to the
>>>>> project.
>>>>>> 
>>>>>> The AT&T framework represents the entire XACML 3.0 object set as a
>>>>> collection of Java interfaces and standard implementations of those
>>>>> interfaces. The AT&T PDP engine is built on top of this framework and
>>>>> represents a complete implementation of a XACML 3.0 PDP, including all
>>>>> of the multi-decision profiles. In addition, the framework also
>>>>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
>>>>> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>>>>> functionality, allowing application developers to simply annotate a
>>>>> Java class to provide attributes for a request. The annotation support
>>>>> removes the need for application developers to learn much of the API.
>>>>>> 
>>>>>> The AT&T framework also includes interfaces and implementations to
>>>>> standardize development of PIP engines that are used by the AT&T PDP
>>>>> implementation, and can be used by other implementations built on top
>>>>> of the AT&T framework. The framework also includes interfaces and
>>>>> implementations for a PAP distributed cloud infrastructure of PDP
>> nodes
>>>>> that includes support for policy distribution and pip configurations.
>>>>> This PAP infrastructure includes a web application administrative
>>>>> console that contains a XACML 3.0 policy editor, attribute dictionary
>>>>> support, and management of PDP RESTful node instances. In addition,
>>>>> there are tools available for policy simulation.
>>>>>> 
>>>>>> Background
>>>>>> 
>>>>>> Access Control is in some ways the most basic IT Security service.
>> It
>>>>> consists of making a decision about whether a particular request
>> should
>>>>> be allowed and enforcing that decision. Aside from schemes like
>>>>> permission bits and Access Control Lists (ACLs) the most common way
>>>>> access control is implemented is as code in a server or application
>>>>> which typically intertwines access control logic with business logic,
>>>>> User interface and other software. This makes it difficult to
>>>>> understand, modify, analyze or even locate the security policy. The
>>>>> primary challenge of Access Control is striking the right balance
>>>>> between powerful expression and intelligibility to human beings.
>>>>>> 
>>>>>> The OASIS XACML Standard exemplifies Attribute-Based Access Control
>>>>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from
>> other
>>>>> components. The Policy Enforcement Point (PEP) must be located so as
>> to
>>>>> be able to enforce the decision, typically near the resource. The PEP
>>>>> first asks the PDP if access should be allowed and provides data, in
>>>>> the form of Attributes, to be used as input to the policies held by
>> the
>>>>> PDP.
>>>>>> 
>>>>>> In addition to responding permit or deny, XACML allows a policy to
>>>>> emit Obligations or Advice, which direct the PEP to do certain things,
>>>>> such logging the access or failure or promising to get rid of the data
>>>>> after 30 days.
>>>>>> 
>>>>>> Attributes are identified as being in a certain category which
>>>>> represents one element in the proposed access. For example attributes
>>>>> may be associated with the resource being accessed, the action being
>>>>> taken or the environment, .e.g. date/time. Attributes may also be
>>>>> associated with any or several types of Subjects, which represent the
>>>>> active parties to the access, such as the requester, intermediaries,
>>>>> the recipient (if different), the codebase, the machine executing the
>>>>> code.
>>>>>> 
>>>>>> Attributes may be provided by the PEP and usually at least a few
>> are,
>>>>> but Attributes may also added by other components of the system. It is
>>>>> also possible for a PDP to add attributes in the middle of policy
>>>>> evaluation. All of these obtain Attributes from the Policy Information
>>>>> Point (PIP).
>>>>>> 
>>>>>> The Policy Administration Point (PAP) creates policies and manages
>>>>> then through their life cycles and generally the entire
>> infrastructure.
>>>>>> 
>>>>>> The XACML language is essentially a set of expressions which
>> evaluate
>>>>> to a Boolean. If true the policy is said to be applicable. The Policy
>>>>> contains permit or deny and may include Permissions and or Advice. If
>>>>> policies disagree we resolve the conflict with combining algorithms.
>>>>> XACML provides some standard ones and you can implement your own.
>>>>> Mostly they are common sense like drop non-applicable polices. A
>>>>> commonly used algorithm is default deny. Deny overrides permit.
>>>>>> 
>>>>>> Rationale
>>>>>> 
>>>>>> Access Control may be the most basic security service, but for the
>>>>> most part it remains primitive in practice. While other services like
>>>>> message protection and authentication have seen many advances in
>> recent
>>>>> years and decades, deployed access control systems are opaque,
>>>>> difficult to us and harder to manage. Most organizations claim that
>>>>> they have security policies, protect privacy and accurately report
>>>>> financial results, but in practice they have no real way of
>> discovering
>>>>> whether their systems actually behave the way they are alleged to do.
>>>>>> 
>>>>>> Just the foreground problems relating to deploying practical ABAC
>>>>> systems make a formidable list. If only the PDP knows what the
>> policies
>>>>> are, how do we make sure it gets the attributes it needs to evaluate
>>>>> policies? How can we name organize, register and dispatch Obligations
>>>>> and Advice, allowing handlers to be provided by the system and added
>> by
>>>>> users? How can the XACML 3.0 feature of being able to create your own
>>>>> attribute categories best be supported by the infrastructure and
>>>>> utilized by users? What are the best ways to create and test policies?
>>>>> What tools will best help us analyze the effects of the policies in
>>>>> force?
>>>>>> 
>>>>>> However, new requirements are rapidly being introduced and need to
>> be
>>>>> met. Privacy requirements continue to increase in complexity and
>> scope.
>>>>> Data which moves around, such as documents, need to be protected. We
>>>>> need secure ways to delegate authority without undermining the
>>>>> integrity of the access control system. New applications, business and
>>>>> social relationships are driving the need for new policy and
>> delegation
>>>>> capabilities.
>>>>>> 
>>>>>> We believe that the way to meet these challenges is to get more
>>>>> people actively engaged in using what is currently available so they
>>>>> can understand its limitations and make it better. We need to make it
>>>>> far easier to get a basic access control infrastructure up and
>> running.
>>>>> We need more people who are familiar with XACML the way many people
>> are
>>>>> familiar with SQL. If as some people say, XACML is the assembly
>>>>> language of access control, we need the real world experience with it
>>>>> that will lead us to the useful abstractions that can be implemented
>> in
>>>>> higher level languages and other tools.
>>>>>> 
>>>>>> Initial Goals
>>>>>> 
>>>>>> Work is currently underway to extend the PEPAPI and increase its
>>>>> flexibility. Since it does not directly correspond to any standard the
>>>>> way AzAPI does, it is necessary to struggle with the issues of what to
>>>>> expose and what to hide from consumers of the API.
>>>>>> 
>>>>>> Other work in progress involves the architecture of Obligations and
>>>>> Advice. There is also an effort to develop a remote client which can
>>>>> easily be dropped into any Java environment and make decision requests
>>>>> of any commercial or open source XACML PDP.
>>>>>> 
>>>>>> The contribution of AT&T's framework creates a need to integrate the
>>>>> prior work with it. Most of the focus will be on AzAPI and the
>>>>> corresponding AT&T API, which do largely the same thing. The result is
>>>>> likely to be a synthesis, since each has features the other lacks.
>> Then
>>>>> PEPAPI will need to be integrated with the new API. The AT&T PDP and
>>>>> PAP will be incorporated as is. There has been some parallel work done
>>>>> in the area of PIPs. Work will be required to understand how to
>> proceed
>>>>> here.
>>>>>> 
>>>>>> Current Status
>>>>>> 
>>>>>> Meritocracy
>>>>>> 
>>>>>> The project was started by Prateek Mishra, Rich Levinson and Hal
>>>>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>>>>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>>>>> Duanhua Tu and Ajith Nair contributed code both using and extending
>>>>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>>>>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
>>>>> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
>>>>> Dragosh and Chris Rath contributed the XACML infrastructure they had
>>>>> developed at AT&T.
>>>>>> 
>>>>>> During most of its history the project has been very small and has
>>>>> made decisions by informal consensus. Major design issues have been
>>>>> decided by open debate. Minor issues and experimental proposals have
>>>>> been openly welcomed. Several of the participants have a background in
>>>>> open consensus-based standards making.
>>>>>> 
>>>>>> In addition to the mailing list, the project has regular phone calls
>>>>> every other Thursday.
>>>>>> 
>>>>>> Community
>>>>>> 
>>>>>> The original focus of the project was to attract developers of XACML
>>>>> products, either individuals or corporations, and to build alignment
>>>>> among vendors on a common API that could simplify technical
>> integration
>>>>> for their customers. As OpenAz has matured, our community has grown to
>>>>> include application developers working to adopt and deploy XACML in
>>>>> their applications. So, for example, contributions reflect what
>>>>> individual developers have learned in vertical industries such as
>>>>> financial services, healthcare, and computing and communications
>>>>> services, and our APIs and internal component architecture have
>> evolved
>>>>> to reflect a strong practical understanding of what it takes to deploy
>>>>> XACML applications in a large organization.
>>>>>> 
>>>>>> Core Developers
>>>>>> 
>>>>>> The following developers have written most of the code to date.
>>>>>> 
>>>>>> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>>>>>> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>>>>>> jpmchase dot com> Chris Rath <car at research dot att dot com>
>>>>> Duanhua
>>>>>> Tu <duanhua.tu at jpmchase dot com>
>>>>>> 
>>>>>> The following people made other significant technical contributions.
>>>>>> 
>>>>>> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>>>>>> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>>>>>> oracle dot com>
>>>>>> 
>>>>>> Alignment
>>>>>> 
>>>>>> It has always been a goal to make OpenAz an Apache project. The
>>>>> Apache license was used for all contributions. We believe the project
>>>>> has now reached a critical size in terms of developers, organizations
>>>>> and contributed code to make it appropriate to make a proposal to the
>>>>> Incubator.
>>>>>> 
>>>>>> Known Risks
>>>>>> 
>>>>>> Orphaned Projects
>>>>>> 
>>>>>> Given the small size of the project, there is a risk of the project
>>>>> being orphaned. There seems to be strong interest in the use of our
>>>>> tools, which should markedly increase with the contribution of the
>> AT&T
>>>>> code. "Where can I get an open source PDP?" and "where can I get an
>>>>> open source policy editor?" are frequent questions on XACML mailing
>>>>> lists.
>>>>>> 
>>>>>> Inexperience with Open Source
>>>>>> 
>>>>>> While few of the developers have extensive experience with open
>>>>> source, a number of us have long experience in standards making in
>> open
>>>>> consensus-based environments. For example the XACML TC has operated
>>>>> since 2001 based on consensus building, with few, if any votes which
>>>>> were not unanimous. The main challenge to the project will be managing
>>>>> the process with more participants and a more formal process.
>>>>>> 
>>>>>> Homogeneous Developers
>>>>>> 
>>>>>> Currently all the contributors are employees either of companies
>>>>> offering an XACML product or large end users deploying XACML
>> technology
>>>>> for internal use. The positive aspect is that they are all highly
>>>>> experienced senior developers used to operating in a disciplined
>>>>> environment. The disadvantage is that the focus to date has mostly
>> been
>>>>> problems that arise in large scale environments typified by the
>>>>> infrastructure of large corporations.
>>>>>> 
>>>>>> Reliance on Salaried Developers
>>>>>> 
>>>>>> All current committers are salaried developers. However the
>>>>> organizations they work for have a long term commitment to the
>>>>> technology. We hope that in the Apache foundation we will be able to
>>>>> attract new developers to help us address the many fascinating
>> unsolved
>>>>> technological problems associated with deploying ABAC.
>>>>>> 
>>>>>> Relationship with other Apache Projects
>>>>>> 
>>>>>> As far as we can determine, no existing Apache project overlaps with
>>>>> OpenAz in its goals of the technology developed so far. However,
>> beyond
>>>>> the immediate project goals there are many potential opportunities for
>>>>> integration with existing Apache projects. Shiro, Turbine and WSS4J
>> are
>>>>> Java frameworks which could incorporate XACML as the policy language
>>>>> using OpenAz components. Manifold CF, Qpid and Archiva already have
>>>>> hooks to incorporate external access control systems.
>>>>>> 
>>>>>> An Excessive Fascination with the Apache Brand
>>>>>> 
>>>>>> We hope that becoming an Apache project will not only attract new
>>>>> participants to OpenAz, but will draw attention to the neglected field
>>>>> of access control. As previously stated it has always been our goal to
>>>>> join Apache, the only question was when the time was ripe.
>>>>>> 
>>>>>> Documentation
>>>>>> 
>>>>>> The OpenAz web site is:
>>>>>> 
>>>>>> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>>>>>> 
>>>>>> Java docs can be found here:
>>>>>> 
>>>>>> 
>>>>> 
>> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
>>>>>> index.html
>>>>>> 
>>>>>> Initial Source
>>>>>> 
>>>>>> The AzAPI, PEPAPI and other related code can be found on
>> sourceforge:
>>>>>> 
>>>>>> http://openaz.svn.sourceforge.net/viewvc/openaz/
>>>>>> 
>>>>>> AT&T's framework can be found on github:
>>>>>> 
>>>>>> https://github.com/att/XACML
>>>>>> 
>>>>>> Source and Intellectual Property Submission Plan
>>>>>> 
>>>>>> All the OpenAz code has been submitted under the Apache 2.0 license.
>>>>> The AT&T software is available under the MIT license. Over time the
>>>>> project will move to a single license.
>>>>>> 
>>>>>> External Dependencies
>>>>>> 
>>>>>> There aren't any we are aware of.
>>>>>> 
>>>>>> Cryptography
>>>>>> 
>>>>>> OpenAz does not provide any cryptographic capabilities. The XACML
>>>>> Standard does specify some uses of cryptography directly, e.g. digital
>>>>> signatures over policies and others by implication, e.g.
>> authentication
>>>>> via cryptography.
>>>>>> 
>>>>>> Required Resources
>>>>>> 
>>>>>> Mailing lists
>>>>>> 
>>>>>> The standard lists should be sufficient at the current time.The
>>>>> mailing list name will be openaz.
>>>>>> 
>>>>>> Git Directory
>>>>>> 
>>>>>> We propose:
>>>>>> https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>>>>>> 
>>>>>> Issue Tracking
>>>>>> 
>>>>>> The project will use JIRA for issue tracking.
>>>>>> 
>>>>>> Initial Committers
>>>>>> 
>>>>>> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>>>>>> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>>>>>> 
>>>>>> Affiliations
>>>>>> 
>>>>>> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle.
>> David
>>>>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>>>>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>>>>>> 
>>>>>> Sponsors
>>>>>> 
>>>>>> Champion
>>>>>> 
>>>>>> Paul Fremantle
>>>>>> 
>>>>>> Nominated Mentors
>>>>>> 
>>>>>> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>>>>>> 
>>>>>> Sponsoring Entity
>>>>>> 
>>>>>> The Sponsoring Entity will be the Incubator.
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-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
>>> 
>>> 
>> 
>> --
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity to
>> which it is addressed and may contain information that is confidential,
>> privileged and exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby notified that
>> any printing, copying, dissemination, distribution, disclosure or
>> forwarding of this communication is strictly prohibited. If you have
>> received this communication in error, please contact the sender immediately
>> and delete it from your system. Thank You.
>> 
> 
> 
> 
> -- 
> 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


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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

+1 from me!

Paul

On Thu, Jan 8, 2015 at 6:10 PM, Dilli Arumugam <da...@hortonworks.com>
wrote:

> +1
>
> On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) <
> pdragosh@research.att.com> wrote:
>
> > +1
> >
> >
> > Pam
> >
> > Pamela L. Dragosh
> > PMTS ­ Research
> > One AT&T Way
> > 4D-170P
> > Bedminster, NJ 07921
> > 908-901-2120 - Office
> > pdragosh@research.att.com
> >
> >
> >
> > On 1/5/15, 2:04 PM, "Hal Lockhart" <ha...@oracle.com> wrote:
> >
> > >I added a comma and the word "and" to the Mentors section. The Mentors
> > >are:
> > >
> > >Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
> > >
> > >Do you see any other formatting errors?
> > >
> > >Hal
> > >
> > >> -----Original Message-----
> > >> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
> > >> Sent: Monday, January 05, 2015 1:24 PM
> > >> To: general@incubator.apache.org
> > >> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
> > >> into the Apache Incubator
> > >>
> > >> Hi!
> > >>
> > >> can you please fix the formatting issues? For example, I can't even
> > >> tell the exact list of mentors you're proposing.
> > >>
> > >> Thanks,
> > >> Roman.
> > >>
> > >> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <
> hal.lockhart@oracle.com>
> > >> wrote:
> > >> > I call a vote to accept OpenAz as a new Incubator project.
> > >> >
> > >> > The proposal can be found here:
> > >> > https://wiki.apache.org/incubator/OpenAZProposal
> > >> >
> > >> > and is included below in this email.
> > >> >
> > >> > Voting will remain open until at least January 20, 2015 23:00 ET.
> > >> >
> > >> > Hal Lockhart
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> -
> > >> > -----------------
> > >> >
> > >> > Abstract
> > >> >
> > >> > OpenAz is a project to create tools and libraries to enable the
> > >> development of Attribute-based Access Control (ABAC) Systems in a
> > >> variety of languages. In general the work is at least consistent with
> > >> or actually conformant to the OASIS XACML Standard.
> > >> >
> > >> > Proposal
> > >> >
> > >> > Generally the work falls into two categories: ready to use tools
> > >> which implement standardized or well understood components of an ABAC
> > >> system and design proposals and proof of concept code relating to less
> > >> well understood or experimental aspects of the problem.
> > >> >
> > >> > Much of the work to date has revolved around defining interfaces
> > >> enabling a PEP to request an access control decision from a PDP. The
> > >> XACML standard defines an abstract request format in xml and protocol
> > >> wire formats in xaml and json, but it does not specify programmatic
> > >> interfaces in any language. The standard says that the use of XML (or
> > >> JSON) is not required only the semantic equivalent.
> > >> >
> > >> > The first Interface, AzAPI is modeled closely on the XACML defined
> > >> interface, expressed in Java. One of the goals was to support calls to
> > >> both a PDP local to the same process and a PDP in a remote server.
> > >> AzAPI includes the interface, reference code to handle things like the
> > >> many supported datatypes in XACML and glue code to mate it to the open
> > >> source Sun XACML implementation.
> > >> >
> > >> > Because of the dependence on Sun XACML (which is XACML 2.0) the
> > >> interface was missing some XACML 3.0 features. More recently this was
> > >> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
> > >> done by the JPMC team to support calling a remote PDP. WSo2 is also
> > >> pursuing this capability.
> > >> >
> > >> > A second, higher level interface, PEPAPI was also defined. PEPAPI is
> > >> more intended for application developers with little knowledge of
> > >> XACML. It allows Java objects which contain attribute information to
> be
> > >> passed in. Conversion methods, called mappers extract information from
> > >> the objects and present it in the format expected by XACML. Some
> > >> implementers have chosen to implement PEPAPI directly against their
> > >> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
> > >> which closely matches the Java one.
> > >> >
> > >> > Examples of more speculative work include: proposals for
> registration
> > >> and dispatch of Obligation and Advice handlers, a scheme called AMF to
> > >> tell PIPs how to retrieve attributes and PIP code to implement it,
> > >> discussion of PoC code to demonstrate the use of XACML policies to
> > >> drive OAuth interations and a proposal to use XACML policies to
> express
> > >> OAuth scope.
> > >> >
> > >> > AT&T has recently contributed their extensive XACML framework to the
> > >> project.
> > >> >
> > >> > The AT&T framework represents the entire XACML 3.0 object set as a
> > >> collection of Java interfaces and standard implementations of those
> > >> interfaces. The AT&T PDP engine is built on top of this framework and
> > >> represents a complete implementation of a XACML 3.0 PDP, including all
> > >> of the multi-decision profiles. In addition, the framework also
> > >> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
> > >> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> > >> functionality, allowing application developers to simply annotate a
> > >> Java class to provide attributes for a request. The annotation support
> > >> removes the need for application developers to learn much of the API.
> > >> >
> > >> > The AT&T framework also includes interfaces and implementations to
> > >> standardize development of PIP engines that are used by the AT&T PDP
> > >> implementation, and can be used by other implementations built on top
> > >> of the AT&T framework. The framework also includes interfaces and
> > >> implementations for a PAP distributed cloud infrastructure of PDP
> nodes
> > >> that includes support for policy distribution and pip configurations.
> > >> This PAP infrastructure includes a web application administrative
> > >> console that contains a XACML 3.0 policy editor, attribute dictionary
> > >> support, and management of PDP RESTful node instances. In addition,
> > >> there are tools available for policy simulation.
> > >> >
> > >> > Background
> > >> >
> > >> > Access Control is in some ways the most basic IT Security service.
> It
> > >> consists of making a decision about whether a particular request
> should
> > >> be allowed and enforcing that decision. Aside from schemes like
> > >> permission bits and Access Control Lists (ACLs) the most common way
> > >> access control is implemented is as code in a server or application
> > >> which typically intertwines access control logic with business logic,
> > >> User interface and other software. This makes it difficult to
> > >> understand, modify, analyze or even locate the security policy. The
> > >> primary challenge of Access Control is striking the right balance
> > >> between powerful expression and intelligibility to human beings.
> > >> >
> > >> > The OASIS XACML Standard exemplifies Attribute-Based Access Control
> > >> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from
> other
> > >> components. The Policy Enforcement Point (PEP) must be located so as
> to
> > >> be able to enforce the decision, typically near the resource. The PEP
> > >> first asks the PDP if access should be allowed and provides data, in
> > >> the form of Attributes, to be used as input to the policies held by
> the
> > >> PDP.
> > >> >
> > >> > In addition to responding permit or deny, XACML allows a policy to
> > >> emit Obligations or Advice, which direct the PEP to do certain things,
> > >> such logging the access or failure or promising to get rid of the data
> > >> after 30 days.
> > >> >
> > >> > Attributes are identified as being in a certain category which
> > >> represents one element in the proposed access. For example attributes
> > >> may be associated with the resource being accessed, the action being
> > >> taken or the environment, .e.g. date/time. Attributes may also be
> > >> associated with any or several types of Subjects, which represent the
> > >> active parties to the access, such as the requester, intermediaries,
> > >> the recipient (if different), the codebase, the machine executing the
> > >> code.
> > >> >
> > >> > Attributes may be provided by the PEP and usually at least a few
> are,
> > >> but Attributes may also added by other components of the system. It is
> > >> also possible for a PDP to add attributes in the middle of policy
> > >> evaluation. All of these obtain Attributes from the Policy Information
> > >> Point (PIP).
> > >> >
> > >> > The Policy Administration Point (PAP) creates policies and manages
> > >> then through their life cycles and generally the entire
> infrastructure.
> > >> >
> > >> > The XACML language is essentially a set of expressions which
> evaluate
> > >> to a Boolean. If true the policy is said to be applicable. The Policy
> > >> contains permit or deny and may include Permissions and or Advice. If
> > >> policies disagree we resolve the conflict with combining algorithms.
> > >> XACML provides some standard ones and you can implement your own.
> > >> Mostly they are common sense like drop non-applicable polices. A
> > >> commonly used algorithm is default deny. Deny overrides permit.
> > >> >
> > >> > Rationale
> > >> >
> > >> > Access Control may be the most basic security service, but for the
> > >> most part it remains primitive in practice. While other services like
> > >> message protection and authentication have seen many advances in
> recent
> > >> years and decades, deployed access control systems are opaque,
> > >> difficult to us and harder to manage. Most organizations claim that
> > >> they have security policies, protect privacy and accurately report
> > >> financial results, but in practice they have no real way of
> discovering
> > >> whether their systems actually behave the way they are alleged to do.
> > >> >
> > >> > Just the foreground problems relating to deploying practical ABAC
> > >> systems make a formidable list. If only the PDP knows what the
> policies
> > >> are, how do we make sure it gets the attributes it needs to evaluate
> > >> policies? How can we name organize, register and dispatch Obligations
> > >> and Advice, allowing handlers to be provided by the system and added
> by
> > >> users? How can the XACML 3.0 feature of being able to create your own
> > >> attribute categories best be supported by the infrastructure and
> > >> utilized by users? What are the best ways to create and test policies?
> > >> What tools will best help us analyze the effects of the policies in
> > >> force?
> > >> >
> > >> > However, new requirements are rapidly being introduced and need to
> be
> > >> met. Privacy requirements continue to increase in complexity and
> scope.
> > >> Data which moves around, such as documents, need to be protected. We
> > >> need secure ways to delegate authority without undermining the
> > >> integrity of the access control system. New applications, business and
> > >> social relationships are driving the need for new policy and
> delegation
> > >> capabilities.
> > >> >
> > >> > We believe that the way to meet these challenges is to get more
> > >> people actively engaged in using what is currently available so they
> > >> can understand its limitations and make it better. We need to make it
> > >> far easier to get a basic access control infrastructure up and
> running.
> > >> We need more people who are familiar with XACML the way many people
> are
> > >> familiar with SQL. If as some people say, XACML is the assembly
> > >> language of access control, we need the real world experience with it
> > >> that will lead us to the useful abstractions that can be implemented
> in
> > >> higher level languages and other tools.
> > >> >
> > >> > Initial Goals
> > >> >
> > >> > Work is currently underway to extend the PEPAPI and increase its
> > >> flexibility. Since it does not directly correspond to any standard the
> > >> way AzAPI does, it is necessary to struggle with the issues of what to
> > >> expose and what to hide from consumers of the API.
> > >> >
> > >> > Other work in progress involves the architecture of Obligations and
> > >> Advice. There is also an effort to develop a remote client which can
> > >> easily be dropped into any Java environment and make decision requests
> > >> of any commercial or open source XACML PDP.
> > >> >
> > >> > The contribution of AT&T's framework creates a need to integrate the
> > >> prior work with it. Most of the focus will be on AzAPI and the
> > >> corresponding AT&T API, which do largely the same thing. The result is
> > >> likely to be a synthesis, since each has features the other lacks.
> Then
> > >> PEPAPI will need to be integrated with the new API. The AT&T PDP and
> > >> PAP will be incorporated as is. There has been some parallel work done
> > >> in the area of PIPs. Work will be required to understand how to
> proceed
> > >> here.
> > >> >
> > >> > Current Status
> > >> >
> > >> > Meritocracy
> > >> >
> > >> > The project was started by Prateek Mishra, Rich Levinson and Hal
> > >> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> > >> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> > >> Duanhua Tu and Ajith Nair contributed code both using and extending
> > >> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> > >> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
> > >> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
> > >> Dragosh and Chris Rath contributed the XACML infrastructure they had
> > >> developed at AT&T.
> > >> >
> > >> > During most of its history the project has been very small and has
> > >> made decisions by informal consensus. Major design issues have been
> > >> decided by open debate. Minor issues and experimental proposals have
> > >> been openly welcomed. Several of the participants have a background in
> > >> open consensus-based standards making.
> > >> >
> > >> > In addition to the mailing list, the project has regular phone calls
> > >> every other Thursday.
> > >> >
> > >> > Community
> > >> >
> > >> > The original focus of the project was to attract developers of XACML
> > >> products, either individuals or corporations, and to build alignment
> > >> among vendors on a common API that could simplify technical
> integration
> > >> for their customers. As OpenAz has matured, our community has grown to
> > >> include application developers working to adopt and deploy XACML in
> > >> their applications. So, for example, contributions reflect what
> > >> individual developers have learned in vertical industries such as
> > >> financial services, healthcare, and computing and communications
> > >> services, and our APIs and internal component architecture have
> evolved
> > >> to reflect a strong practical understanding of what it takes to deploy
> > >> XACML applications in a large organization.
> > >> >
> > >> > Core Developers
> > >> >
> > >> > The following developers have written most of the code to date.
> > >> >
> > >> > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> > >> > rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> > >> > jpmchase dot com> Chris Rath <car at research dot att dot com>
> > >> Duanhua
> > >> > Tu <duanhua.tu at jpmchase dot com>
> > >> >
> > >> > The following people made other significant technical contributions.
> > >> >
> > >> > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> > >> > <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> > >> > oracle dot com>
> > >> >
> > >> > Alignment
> > >> >
> > >> > It has always been a goal to make OpenAz an Apache project. The
> > >> Apache license was used for all contributions. We believe the project
> > >> has now reached a critical size in terms of developers, organizations
> > >> and contributed code to make it appropriate to make a proposal to the
> > >> Incubator.
> > >> >
> > >> > Known Risks
> > >> >
> > >> > Orphaned Projects
> > >> >
> > >> > Given the small size of the project, there is a risk of the project
> > >> being orphaned. There seems to be strong interest in the use of our
> > >> tools, which should markedly increase with the contribution of the
> AT&T
> > >> code. "Where can I get an open source PDP?" and "where can I get an
> > >> open source policy editor?" are frequent questions on XACML mailing
> > >> lists.
> > >> >
> > >> > Inexperience with Open Source
> > >> >
> > >> > While few of the developers have extensive experience with open
> > >> source, a number of us have long experience in standards making in
> open
> > >> consensus-based environments. For example the XACML TC has operated
> > >> since 2001 based on consensus building, with few, if any votes which
> > >> were not unanimous. The main challenge to the project will be managing
> > >> the process with more participants and a more formal process.
> > >> >
> > >> > Homogeneous Developers
> > >> >
> > >> > Currently all the contributors are employees either of companies
> > >> offering an XACML product or large end users deploying XACML
> technology
> > >> for internal use. The positive aspect is that they are all highly
> > >> experienced senior developers used to operating in a disciplined
> > >> environment. The disadvantage is that the focus to date has mostly
> been
> > >> problems that arise in large scale environments typified by the
> > >> infrastructure of large corporations.
> > >> >
> > >> > Reliance on Salaried Developers
> > >> >
> > >> > All current committers are salaried developers. However the
> > >> organizations they work for have a long term commitment to the
> > >> technology. We hope that in the Apache foundation we will be able to
> > >> attract new developers to help us address the many fascinating
> unsolved
> > >> technological problems associated with deploying ABAC.
> > >> >
> > >> > Relationship with other Apache Projects
> > >> >
> > >> > As far as we can determine, no existing Apache project overlaps with
> > >> OpenAz in its goals of the technology developed so far. However,
> beyond
> > >> the immediate project goals there are many potential opportunities for
> > >> integration with existing Apache projects. Shiro, Turbine and WSS4J
> are
> > >> Java frameworks which could incorporate XACML as the policy language
> > >> using OpenAz components. Manifold CF, Qpid and Archiva already have
> > >> hooks to incorporate external access control systems.
> > >> >
> > >> > An Excessive Fascination with the Apache Brand
> > >> >
> > >> > We hope that becoming an Apache project will not only attract new
> > >> participants to OpenAz, but will draw attention to the neglected field
> > >> of access control. As previously stated it has always been our goal to
> > >> join Apache, the only question was when the time was ripe.
> > >> >
> > >> > Documentation
> > >> >
> > >> > The OpenAz web site is:
> > >> >
> > >> > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> > >> >
> > >> > Java docs can be found here:
> > >> >
> > >> >
> > >>
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
> > >> > index.html
> > >> >
> > >> > Initial Source
> > >> >
> > >> > The AzAPI, PEPAPI and other related code can be found on
> sourceforge:
> > >> >
> > >> > http://openaz.svn.sourceforge.net/viewvc/openaz/
> > >> >
> > >> > AT&T's framework can be found on github:
> > >> >
> > >> > https://github.com/att/XACML
> > >> >
> > >> > Source and Intellectual Property Submission Plan
> > >> >
> > >> > All the OpenAz code has been submitted under the Apache 2.0 license.
> > >> The AT&T software is available under the MIT license. Over time the
> > >> project will move to a single license.
> > >> >
> > >> > External Dependencies
> > >> >
> > >> > There aren't any we are aware of.
> > >> >
> > >> > Cryptography
> > >> >
> > >> > OpenAz does not provide any cryptographic capabilities. The XACML
> > >> Standard does specify some uses of cryptography directly, e.g. digital
> > >> signatures over policies and others by implication, e.g.
> authentication
> > >> via cryptography.
> > >> >
> > >> > Required Resources
> > >> >
> > >> > Mailing lists
> > >> >
> > >> > The standard lists should be sufficient at the current time.The
> > >> mailing list name will be openaz.
> > >> >
> > >> > Git Directory
> > >> >
> > >> > We propose:
> > >> > https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
> > >> >
> > >> > Issue Tracking
> > >> >
> > >> > The project will use JIRA for issue tracking.
> > >> >
> > >> > Initial Committers
> > >> >
> > >> > Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> > >> > Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> > >> >
> > >> > Affiliations
> > >> >
> > >> > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle.
> David
> > >> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> > >> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> > >> >
> > >> > Sponsors
> > >> >
> > >> > Champion
> > >> >
> > >> > Paul Fremantle
> > >> >
> > >> > Nominated Mentors
> > >> >
> > >> > Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> > >> >
> > >> > Sponsoring Entity
> > >> >
> > >> > The Sponsoring Entity will be the Incubator.
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: general-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
> >
> >
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>



-- 
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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Dilli Arumugam <da...@hortonworks.com>]

+1

On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) <
pdragosh@research.att.com> wrote:

> +1
>
>
> Pam
>
> Pamela L. Dragosh
> PMTS ­ Research
> One AT&T Way
> 4D-170P
> Bedminster, NJ 07921
> 908-901-2120 - Office
> pdragosh@research.att.com
>
>
>
> On 1/5/15, 2:04 PM, "Hal Lockhart" <ha...@oracle.com> wrote:
>
> >I added a comma and the word "and" to the Mentors section. The Mentors
> >are:
> >
> >Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
> >
> >Do you see any other formatting errors?
> >
> >Hal
> >
> >> -----Original Message-----
> >> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
> >> Sent: Monday, January 05, 2015 1:24 PM
> >> To: general@incubator.apache.org
> >> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
> >> into the Apache Incubator
> >>
> >> Hi!
> >>
> >> can you please fix the formatting issues? For example, I can't even
> >> tell the exact list of mentors you're proposing.
> >>
> >> Thanks,
> >> Roman.
> >>
> >> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com>
> >> wrote:
> >> > I call a vote to accept OpenAz as a new Incubator project.
> >> >
> >> > The proposal can be found here:
> >> > https://wiki.apache.org/incubator/OpenAZProposal
> >> >
> >> > and is included below in this email.
> >> >
> >> > Voting will remain open until at least January 20, 2015 23:00 ET.
> >> >
> >> > Hal Lockhart
> >> >
> >> > ---------------------------------------------------------------------
> >> -
> >> > -----------------
> >> >
> >> > Abstract
> >> >
> >> > OpenAz is a project to create tools and libraries to enable the
> >> development of Attribute-based Access Control (ABAC) Systems in a
> >> variety of languages. In general the work is at least consistent with
> >> or actually conformant to the OASIS XACML Standard.
> >> >
> >> > Proposal
> >> >
> >> > Generally the work falls into two categories: ready to use tools
> >> which implement standardized or well understood components of an ABAC
> >> system and design proposals and proof of concept code relating to less
> >> well understood or experimental aspects of the problem.
> >> >
> >> > Much of the work to date has revolved around defining interfaces
> >> enabling a PEP to request an access control decision from a PDP. The
> >> XACML standard defines an abstract request format in xml and protocol
> >> wire formats in xaml and json, but it does not specify programmatic
> >> interfaces in any language. The standard says that the use of XML (or
> >> JSON) is not required only the semantic equivalent.
> >> >
> >> > The first Interface, AzAPI is modeled closely on the XACML defined
> >> interface, expressed in Java. One of the goals was to support calls to
> >> both a PDP local to the same process and a PDP in a remote server.
> >> AzAPI includes the interface, reference code to handle things like the
> >> many supported datatypes in XACML and glue code to mate it to the open
> >> source Sun XACML implementation.
> >> >
> >> > Because of the dependence on Sun XACML (which is XACML 2.0) the
> >> interface was missing some XACML 3.0 features. More recently this was
> >> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
> >> done by the JPMC team to support calling a remote PDP. WSo2 is also
> >> pursuing this capability.
> >> >
> >> > A second, higher level interface, PEPAPI was also defined. PEPAPI is
> >> more intended for application developers with little knowledge of
> >> XACML. It allows Java objects which contain attribute information to be
> >> passed in. Conversion methods, called mappers extract information from
> >> the objects and present it in the format expected by XACML. Some
> >> implementers have chosen to implement PEPAPI directly against their
> >> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
> >> which closely matches the Java one.
> >> >
> >> > Examples of more speculative work include: proposals for registration
> >> and dispatch of Obligation and Advice handlers, a scheme called AMF to
> >> tell PIPs how to retrieve attributes and PIP code to implement it,
> >> discussion of PoC code to demonstrate the use of XACML policies to
> >> drive OAuth interations and a proposal to use XACML policies to express
> >> OAuth scope.
> >> >
> >> > AT&T has recently contributed their extensive XACML framework to the
> >> project.
> >> >
> >> > The AT&T framework represents the entire XACML 3.0 object set as a
> >> collection of Java interfaces and standard implementations of those
> >> interfaces. The AT&T PDP engine is built on top of this framework and
> >> represents a complete implementation of a XACML 3.0 PDP, including all
> >> of the multi-decision profiles. In addition, the framework also
> >> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
> >> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> >> functionality, allowing application developers to simply annotate a
> >> Java class to provide attributes for a request. The annotation support
> >> removes the need for application developers to learn much of the API.
> >> >
> >> > The AT&T framework also includes interfaces and implementations to
> >> standardize development of PIP engines that are used by the AT&T PDP
> >> implementation, and can be used by other implementations built on top
> >> of the AT&T framework. The framework also includes interfaces and
> >> implementations for a PAP distributed cloud infrastructure of PDP nodes
> >> that includes support for policy distribution and pip configurations.
> >> This PAP infrastructure includes a web application administrative
> >> console that contains a XACML 3.0 policy editor, attribute dictionary
> >> support, and management of PDP RESTful node instances. In addition,
> >> there are tools available for policy simulation.
> >> >
> >> > Background
> >> >
> >> > Access Control is in some ways the most basic IT Security service. It
> >> consists of making a decision about whether a particular request should
> >> be allowed and enforcing that decision. Aside from schemes like
> >> permission bits and Access Control Lists (ACLs) the most common way
> >> access control is implemented is as code in a server or application
> >> which typically intertwines access control logic with business logic,
> >> User interface and other software. This makes it difficult to
> >> understand, modify, analyze or even locate the security policy. The
> >> primary challenge of Access Control is striking the right balance
> >> between powerful expression and intelligibility to human beings.
> >> >
> >> > The OASIS XACML Standard exemplifies Attribute-Based Access Control
> >> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
> >> components. The Policy Enforcement Point (PEP) must be located so as to
> >> be able to enforce the decision, typically near the resource. The PEP
> >> first asks the PDP if access should be allowed and provides data, in
> >> the form of Attributes, to be used as input to the policies held by the
> >> PDP.
> >> >
> >> > In addition to responding permit or deny, XACML allows a policy to
> >> emit Obligations or Advice, which direct the PEP to do certain things,
> >> such logging the access or failure or promising to get rid of the data
> >> after 30 days.
> >> >
> >> > Attributes are identified as being in a certain category which
> >> represents one element in the proposed access. For example attributes
> >> may be associated with the resource being accessed, the action being
> >> taken or the environment, .e.g. date/time. Attributes may also be
> >> associated with any or several types of Subjects, which represent the
> >> active parties to the access, such as the requester, intermediaries,
> >> the recipient (if different), the codebase, the machine executing the
> >> code.
> >> >
> >> > Attributes may be provided by the PEP and usually at least a few are,
> >> but Attributes may also added by other components of the system. It is
> >> also possible for a PDP to add attributes in the middle of policy
> >> evaluation. All of these obtain Attributes from the Policy Information
> >> Point (PIP).
> >> >
> >> > The Policy Administration Point (PAP) creates policies and manages
> >> then through their life cycles and generally the entire infrastructure.
> >> >
> >> > The XACML language is essentially a set of expressions which evaluate
> >> to a Boolean. If true the policy is said to be applicable. The Policy
> >> contains permit or deny and may include Permissions and or Advice. If
> >> policies disagree we resolve the conflict with combining algorithms.
> >> XACML provides some standard ones and you can implement your own.
> >> Mostly they are common sense like drop non-applicable polices. A
> >> commonly used algorithm is default deny. Deny overrides permit.
> >> >
> >> > Rationale
> >> >
> >> > Access Control may be the most basic security service, but for the
> >> most part it remains primitive in practice. While other services like
> >> message protection and authentication have seen many advances in recent
> >> years and decades, deployed access control systems are opaque,
> >> difficult to us and harder to manage. Most organizations claim that
> >> they have security policies, protect privacy and accurately report
> >> financial results, but in practice they have no real way of discovering
> >> whether their systems actually behave the way they are alleged to do.
> >> >
> >> > Just the foreground problems relating to deploying practical ABAC
> >> systems make a formidable list. If only the PDP knows what the policies
> >> are, how do we make sure it gets the attributes it needs to evaluate
> >> policies? How can we name organize, register and dispatch Obligations
> >> and Advice, allowing handlers to be provided by the system and added by
> >> users? How can the XACML 3.0 feature of being able to create your own
> >> attribute categories best be supported by the infrastructure and
> >> utilized by users? What are the best ways to create and test policies?
> >> What tools will best help us analyze the effects of the policies in
> >> force?
> >> >
> >> > However, new requirements are rapidly being introduced and need to be
> >> met. Privacy requirements continue to increase in complexity and scope.
> >> Data which moves around, such as documents, need to be protected. We
> >> need secure ways to delegate authority without undermining the
> >> integrity of the access control system. New applications, business and
> >> social relationships are driving the need for new policy and delegation
> >> capabilities.
> >> >
> >> > We believe that the way to meet these challenges is to get more
> >> people actively engaged in using what is currently available so they
> >> can understand its limitations and make it better. We need to make it
> >> far easier to get a basic access control infrastructure up and running.
> >> We need more people who are familiar with XACML the way many people are
> >> familiar with SQL. If as some people say, XACML is the assembly
> >> language of access control, we need the real world experience with it
> >> that will lead us to the useful abstractions that can be implemented in
> >> higher level languages and other tools.
> >> >
> >> > Initial Goals
> >> >
> >> > Work is currently underway to extend the PEPAPI and increase its
> >> flexibility. Since it does not directly correspond to any standard the
> >> way AzAPI does, it is necessary to struggle with the issues of what to
> >> expose and what to hide from consumers of the API.
> >> >
> >> > Other work in progress involves the architecture of Obligations and
> >> Advice. There is also an effort to develop a remote client which can
> >> easily be dropped into any Java environment and make decision requests
> >> of any commercial or open source XACML PDP.
> >> >
> >> > The contribution of AT&T's framework creates a need to integrate the
> >> prior work with it. Most of the focus will be on AzAPI and the
> >> corresponding AT&T API, which do largely the same thing. The result is
> >> likely to be a synthesis, since each has features the other lacks. Then
> >> PEPAPI will need to be integrated with the new API. The AT&T PDP and
> >> PAP will be incorporated as is. There has been some parallel work done
> >> in the area of PIPs. Work will be required to understand how to proceed
> >> here.
> >> >
> >> > Current Status
> >> >
> >> > Meritocracy
> >> >
> >> > The project was started by Prateek Mishra, Rich Levinson and Hal
> >> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> >> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> >> Duanhua Tu and Ajith Nair contributed code both using and extending
> >> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> >> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
> >> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
> >> Dragosh and Chris Rath contributed the XACML infrastructure they had
> >> developed at AT&T.
> >> >
> >> > During most of its history the project has been very small and has
> >> made decisions by informal consensus. Major design issues have been
> >> decided by open debate. Minor issues and experimental proposals have
> >> been openly welcomed. Several of the participants have a background in
> >> open consensus-based standards making.
> >> >
> >> > In addition to the mailing list, the project has regular phone calls
> >> every other Thursday.
> >> >
> >> > Community
> >> >
> >> > The original focus of the project was to attract developers of XACML
> >> products, either individuals or corporations, and to build alignment
> >> among vendors on a common API that could simplify technical integration
> >> for their customers. As OpenAz has matured, our community has grown to
> >> include application developers working to adopt and deploy XACML in
> >> their applications. So, for example, contributions reflect what
> >> individual developers have learned in vertical industries such as
> >> financial services, healthcare, and computing and communications
> >> services, and our APIs and internal component architecture have evolved
> >> to reflect a strong practical understanding of what it takes to deploy
> >> XACML applications in a large organization.
> >> >
> >> > Core Developers
> >> >
> >> > The following developers have written most of the code to date.
> >> >
> >> > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> >> > rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> >> > jpmchase dot com> Chris Rath <car at research dot att dot com>
> >> Duanhua
> >> > Tu <duanhua.tu at jpmchase dot com>
> >> >
> >> > The following people made other significant technical contributions.
> >> >
> >> > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> >> > <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> >> > oracle dot com>
> >> >
> >> > Alignment
> >> >
> >> > It has always been a goal to make OpenAz an Apache project. The
> >> Apache license was used for all contributions. We believe the project
> >> has now reached a critical size in terms of developers, organizations
> >> and contributed code to make it appropriate to make a proposal to the
> >> Incubator.
> >> >
> >> > Known Risks
> >> >
> >> > Orphaned Projects
> >> >
> >> > Given the small size of the project, there is a risk of the project
> >> being orphaned. There seems to be strong interest in the use of our
> >> tools, which should markedly increase with the contribution of the AT&T
> >> code. "Where can I get an open source PDP?" and "where can I get an
> >> open source policy editor?" are frequent questions on XACML mailing
> >> lists.
> >> >
> >> > Inexperience with Open Source
> >> >
> >> > While few of the developers have extensive experience with open
> >> source, a number of us have long experience in standards making in open
> >> consensus-based environments. For example the XACML TC has operated
> >> since 2001 based on consensus building, with few, if any votes which
> >> were not unanimous. The main challenge to the project will be managing
> >> the process with more participants and a more formal process.
> >> >
> >> > Homogeneous Developers
> >> >
> >> > Currently all the contributors are employees either of companies
> >> offering an XACML product or large end users deploying XACML technology
> >> for internal use. The positive aspect is that they are all highly
> >> experienced senior developers used to operating in a disciplined
> >> environment. The disadvantage is that the focus to date has mostly been
> >> problems that arise in large scale environments typified by the
> >> infrastructure of large corporations.
> >> >
> >> > Reliance on Salaried Developers
> >> >
> >> > All current committers are salaried developers. However the
> >> organizations they work for have a long term commitment to the
> >> technology. We hope that in the Apache foundation we will be able to
> >> attract new developers to help us address the many fascinating unsolved
> >> technological problems associated with deploying ABAC.
> >> >
> >> > Relationship with other Apache Projects
> >> >
> >> > As far as we can determine, no existing Apache project overlaps with
> >> OpenAz in its goals of the technology developed so far. However, beyond
> >> the immediate project goals there are many potential opportunities for
> >> integration with existing Apache projects. Shiro, Turbine and WSS4J are
> >> Java frameworks which could incorporate XACML as the policy language
> >> using OpenAz components. Manifold CF, Qpid and Archiva already have
> >> hooks to incorporate external access control systems.
> >> >
> >> > An Excessive Fascination with the Apache Brand
> >> >
> >> > We hope that becoming an Apache project will not only attract new
> >> participants to OpenAz, but will draw attention to the neglected field
> >> of access control. As previously stated it has always been our goal to
> >> join Apache, the only question was when the time was ripe.
> >> >
> >> > Documentation
> >> >
> >> > The OpenAz web site is:
> >> >
> >> > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> >> >
> >> > Java docs can be found here:
> >> >
> >> >
> >> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
> >> > index.html
> >> >
> >> > Initial Source
> >> >
> >> > The AzAPI, PEPAPI and other related code can be found on sourceforge:
> >> >
> >> > http://openaz.svn.sourceforge.net/viewvc/openaz/
> >> >
> >> > AT&T's framework can be found on github:
> >> >
> >> > https://github.com/att/XACML
> >> >
> >> > Source and Intellectual Property Submission Plan
> >> >
> >> > All the OpenAz code has been submitted under the Apache 2.0 license.
> >> The AT&T software is available under the MIT license. Over time the
> >> project will move to a single license.
> >> >
> >> > External Dependencies
> >> >
> >> > There aren't any we are aware of.
> >> >
> >> > Cryptography
> >> >
> >> > OpenAz does not provide any cryptographic capabilities. The XACML
> >> Standard does specify some uses of cryptography directly, e.g. digital
> >> signatures over policies and others by implication, e.g. authentication
> >> via cryptography.
> >> >
> >> > Required Resources
> >> >
> >> > Mailing lists
> >> >
> >> > The standard lists should be sufficient at the current time.The
> >> mailing list name will be openaz.
> >> >
> >> > Git Directory
> >> >
> >> > We propose:
> >> > https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
> >> >
> >> > Issue Tracking
> >> >
> >> > The project will use JIRA for issue tracking.
> >> >
> >> > Initial Committers
> >> >
> >> > Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> >> > Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> >> >
> >> > Affiliations
> >> >
> >> > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> >> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> >> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> >> >
> >> > Sponsors
> >> >
> >> > Champion
> >> >
> >> > Paul Fremantle
> >> >
> >> > Nominated Mentors
> >> >
> >> > Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> >> >
> >> > Sponsoring Entity
> >> >
> >> > The Sponsoring Entity will be the Incubator.
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: general-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
>
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

["DRAGOSH, PAMELA L (PAM)" <pd...@research.att.com>]

+1


Pam

Pamela L. Dragosh
PMTS ­ Research
One AT&T Way
4D-170P
Bedminster, NJ 07921
908-901-2120 - Office
pdragosh@research.att.com



On 1/5/15, 2:04 PM, "Hal Lockhart" <ha...@oracle.com> wrote:

>I added a comma and the word "and" to the Mentors section. The Mentors
>are:
>
>Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea
>
>Do you see any other formatting errors?
>
>Hal
>
>> -----Original Message-----
>> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
>> Sent: Monday, January 05, 2015 1:24 PM
>> To: general@incubator.apache.org
>> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
>> into the Apache Incubator
>>
>> Hi!
>>
>> can you please fix the formatting issues? For example, I can't even
>> tell the exact list of mentors you're proposing.
>>
>> Thanks,
>> Roman.
>>
>> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com>
>> wrote:
>> > I call a vote to accept OpenAz as a new Incubator project.
>> >
>> > The proposal can be found here:
>> > https://wiki.apache.org/incubator/OpenAZProposal
>> >
>> > and is included below in this email.
>> >
>> > Voting will remain open until at least January 20, 2015 23:00 ET.
>> >
>> > Hal Lockhart
>> >
>> > ---------------------------------------------------------------------
>> -
>> > -----------------
>> >
>> > Abstract
>> >
>> > OpenAz is a project to create tools and libraries to enable the
>> development of Attribute-based Access Control (ABAC) Systems in a
>> variety of languages. In general the work is at least consistent with
>> or actually conformant to the OASIS XACML Standard.
>> >
>> > Proposal
>> >
>> > Generally the work falls into two categories: ready to use tools
>> which implement standardized or well understood components of an ABAC
>> system and design proposals and proof of concept code relating to less
>> well understood or experimental aspects of the problem.
>> >
>> > Much of the work to date has revolved around defining interfaces
>> enabling a PEP to request an access control decision from a PDP. The
>> XACML standard defines an abstract request format in xml and protocol
>> wire formats in xaml and json, but it does not specify programmatic
>> interfaces in any language. The standard says that the use of XML (or
>> JSON) is not required only the semantic equivalent.
>> >
>> > The first Interface, AzAPI is modeled closely on the XACML defined
>> interface, expressed in Java. One of the goals was to support calls to
>> both a PDP local to the same process and a PDP in a remote server.
>> AzAPI includes the interface, reference code to handle things like the
>> many supported datatypes in XACML and glue code to mate it to the open
>> source Sun XACML implementation.
>> >
>> > Because of the dependence on Sun XACML (which is XACML 2.0) the
>> interface was missing some XACML 3.0 features. More recently this was
>> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
>> done by the JPMC team to support calling a remote PDP. WSo2 is also
>> pursuing this capability.
>> >
>> > A second, higher level interface, PEPAPI was also defined. PEPAPI is
>> more intended for application developers with little knowledge of
>> XACML. It allows Java objects which contain attribute information to be
>> passed in. Conversion methods, called mappers extract information from
>> the objects and present it in the format expected by XACML. Some
>> implementers have chosen to implement PEPAPI directly against their
>> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
>> which closely matches the Java one.
>> >
>> > Examples of more speculative work include: proposals for registration
>> and dispatch of Obligation and Advice handlers, a scheme called AMF to
>> tell PIPs how to retrieve attributes and PIP code to implement it,
>> discussion of PoC code to demonstrate the use of XACML policies to
>> drive OAuth interations and a proposal to use XACML policies to express
>> OAuth scope.
>> >
>> > AT&T has recently contributed their extensive XACML framework to the
>> project.
>> >
>> > The AT&T framework represents the entire XACML 3.0 object set as a
>> collection of Java interfaces and standard implementations of those
>> interfaces. The AT&T PDP engine is built on top of this framework and
>> represents a complete implementation of a XACML 3.0 PDP, including all
>> of the multi-decision profiles. In addition, the framework also
>> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
>> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
>> functionality, allowing application developers to simply annotate a
>> Java class to provide attributes for a request. The annotation support
>> removes the need for application developers to learn much of the API.
>> >
>> > The AT&T framework also includes interfaces and implementations to
>> standardize development of PIP engines that are used by the AT&T PDP
>> implementation, and can be used by other implementations built on top
>> of the AT&T framework. The framework also includes interfaces and
>> implementations for a PAP distributed cloud infrastructure of PDP nodes
>> that includes support for policy distribution and pip configurations.
>> This PAP infrastructure includes a web application administrative
>> console that contains a XACML 3.0 policy editor, attribute dictionary
>> support, and management of PDP RESTful node instances. In addition,
>> there are tools available for policy simulation.
>> >
>> > Background
>> >
>> > Access Control is in some ways the most basic IT Security service. It
>> consists of making a decision about whether a particular request should
>> be allowed and enforcing that decision. Aside from schemes like
>> permission bits and Access Control Lists (ACLs) the most common way
>> access control is implemented is as code in a server or application
>> which typically intertwines access control logic with business logic,
>> User interface and other software. This makes it difficult to
>> understand, modify, analyze or even locate the security policy. The
>> primary challenge of Access Control is striking the right balance
>> between powerful expression and intelligibility to human beings.
>> >
>> > The OASIS XACML Standard exemplifies Attribute-Based Access Control
>> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
>> components. The Policy Enforcement Point (PEP) must be located so as to
>> be able to enforce the decision, typically near the resource. The PEP
>> first asks the PDP if access should be allowed and provides data, in
>> the form of Attributes, to be used as input to the policies held by the
>> PDP.
>> >
>> > In addition to responding permit or deny, XACML allows a policy to
>> emit Obligations or Advice, which direct the PEP to do certain things,
>> such logging the access or failure or promising to get rid of the data
>> after 30 days.
>> >
>> > Attributes are identified as being in a certain category which
>> represents one element in the proposed access. For example attributes
>> may be associated with the resource being accessed, the action being
>> taken or the environment, .e.g. date/time. Attributes may also be
>> associated with any or several types of Subjects, which represent the
>> active parties to the access, such as the requester, intermediaries,
>> the recipient (if different), the codebase, the machine executing the
>> code.
>> >
>> > Attributes may be provided by the PEP and usually at least a few are,
>> but Attributes may also added by other components of the system. It is
>> also possible for a PDP to add attributes in the middle of policy
>> evaluation. All of these obtain Attributes from the Policy Information
>> Point (PIP).
>> >
>> > The Policy Administration Point (PAP) creates policies and manages
>> then through their life cycles and generally the entire infrastructure.
>> >
>> > The XACML language is essentially a set of expressions which evaluate
>> to a Boolean. If true the policy is said to be applicable. The Policy
>> contains permit or deny and may include Permissions and or Advice. If
>> policies disagree we resolve the conflict with combining algorithms.
>> XACML provides some standard ones and you can implement your own.
>> Mostly they are common sense like drop non-applicable polices. A
>> commonly used algorithm is default deny. Deny overrides permit.
>> >
>> > Rationale
>> >
>> > Access Control may be the most basic security service, but for the
>> most part it remains primitive in practice. While other services like
>> message protection and authentication have seen many advances in recent
>> years and decades, deployed access control systems are opaque,
>> difficult to us and harder to manage. Most organizations claim that
>> they have security policies, protect privacy and accurately report
>> financial results, but in practice they have no real way of discovering
>> whether their systems actually behave the way they are alleged to do.
>> >
>> > Just the foreground problems relating to deploying practical ABAC
>> systems make a formidable list. If only the PDP knows what the policies
>> are, how do we make sure it gets the attributes it needs to evaluate
>> policies? How can we name organize, register and dispatch Obligations
>> and Advice, allowing handlers to be provided by the system and added by
>> users? How can the XACML 3.0 feature of being able to create your own
>> attribute categories best be supported by the infrastructure and
>> utilized by users? What are the best ways to create and test policies?
>> What tools will best help us analyze the effects of the policies in
>> force?
>> >
>> > However, new requirements are rapidly being introduced and need to be
>> met. Privacy requirements continue to increase in complexity and scope.
>> Data which moves around, such as documents, need to be protected. We
>> need secure ways to delegate authority without undermining the
>> integrity of the access control system. New applications, business and
>> social relationships are driving the need for new policy and delegation
>> capabilities.
>> >
>> > We believe that the way to meet these challenges is to get more
>> people actively engaged in using what is currently available so they
>> can understand its limitations and make it better. We need to make it
>> far easier to get a basic access control infrastructure up and running.
>> We need more people who are familiar with XACML the way many people are
>> familiar with SQL. If as some people say, XACML is the assembly
>> language of access control, we need the real world experience with it
>> that will lead us to the useful abstractions that can be implemented in
>> higher level languages and other tools.
>> >
>> > Initial Goals
>> >
>> > Work is currently underway to extend the PEPAPI and increase its
>> flexibility. Since it does not directly correspond to any standard the
>> way AzAPI does, it is necessary to struggle with the issues of what to
>> expose and what to hide from consumers of the API.
>> >
>> > Other work in progress involves the architecture of Obligations and
>> Advice. There is also an effort to develop a remote client which can
>> easily be dropped into any Java environment and make decision requests
>> of any commercial or open source XACML PDP.
>> >
>> > The contribution of AT&T's framework creates a need to integrate the
>> prior work with it. Most of the focus will be on AzAPI and the
>> corresponding AT&T API, which do largely the same thing. The result is
>> likely to be a synthesis, since each has features the other lacks. Then
>> PEPAPI will need to be integrated with the new API. The AT&T PDP and
>> PAP will be incorporated as is. There has been some parallel work done
>> in the area of PIPs. Work will be required to understand how to proceed
>> here.
>> >
>> > Current Status
>> >
>> > Meritocracy
>> >
>> > The project was started by Prateek Mishra, Rich Levinson and Hal
>> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
>> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
>> Duanhua Tu and Ajith Nair contributed code both using and extending
>> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
>> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
>> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
>> Dragosh and Chris Rath contributed the XACML infrastructure they had
>> developed at AT&T.
>> >
>> > During most of its history the project has been very small and has
>> made decisions by informal consensus. Major design issues have been
>> decided by open debate. Minor issues and experimental proposals have
>> been openly welcomed. Several of the participants have a background in
>> open consensus-based standards making.
>> >
>> > In addition to the mailing list, the project has regular phone calls
>> every other Thursday.
>> >
>> > Community
>> >
>> > The original focus of the project was to attract developers of XACML
>> products, either individuals or corporations, and to build alignment
>> among vendors on a common API that could simplify technical integration
>> for their customers. As OpenAz has matured, our community has grown to
>> include application developers working to adopt and deploy XACML in
>> their applications. So, for example, contributions reflect what
>> individual developers have learned in vertical industries such as
>> financial services, healthcare, and computing and communications
>> services, and our APIs and internal component architecture have evolved
>> to reflect a strong practical understanding of what it takes to deploy
>> XACML applications in a large organization.
>> >
>> > Core Developers
>> >
>> > The following developers have written most of the code to date.
>> >
>> > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
>> > rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
>> > jpmchase dot com> Chris Rath <car at research dot att dot com>
>> Duanhua
>> > Tu <duanhua.tu at jpmchase dot com>
>> >
>> > The following people made other significant technical contributions.
>> >
>> > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
>> > <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
>> > oracle dot com>
>> >
>> > Alignment
>> >
>> > It has always been a goal to make OpenAz an Apache project. The
>> Apache license was used for all contributions. We believe the project
>> has now reached a critical size in terms of developers, organizations
>> and contributed code to make it appropriate to make a proposal to the
>> Incubator.
>> >
>> > Known Risks
>> >
>> > Orphaned Projects
>> >
>> > Given the small size of the project, there is a risk of the project
>> being orphaned. There seems to be strong interest in the use of our
>> tools, which should markedly increase with the contribution of the AT&T
>> code. "Where can I get an open source PDP?" and "where can I get an
>> open source policy editor?" are frequent questions on XACML mailing
>> lists.
>> >
>> > Inexperience with Open Source
>> >
>> > While few of the developers have extensive experience with open
>> source, a number of us have long experience in standards making in open
>> consensus-based environments. For example the XACML TC has operated
>> since 2001 based on consensus building, with few, if any votes which
>> were not unanimous. The main challenge to the project will be managing
>> the process with more participants and a more formal process.
>> >
>> > Homogeneous Developers
>> >
>> > Currently all the contributors are employees either of companies
>> offering an XACML product or large end users deploying XACML technology
>> for internal use. The positive aspect is that they are all highly
>> experienced senior developers used to operating in a disciplined
>> environment. The disadvantage is that the focus to date has mostly been
>> problems that arise in large scale environments typified by the
>> infrastructure of large corporations.
>> >
>> > Reliance on Salaried Developers
>> >
>> > All current committers are salaried developers. However the
>> organizations they work for have a long term commitment to the
>> technology. We hope that in the Apache foundation we will be able to
>> attract new developers to help us address the many fascinating unsolved
>> technological problems associated with deploying ABAC.
>> >
>> > Relationship with other Apache Projects
>> >
>> > As far as we can determine, no existing Apache project overlaps with
>> OpenAz in its goals of the technology developed so far. However, beyond
>> the immediate project goals there are many potential opportunities for
>> integration with existing Apache projects. Shiro, Turbine and WSS4J are
>> Java frameworks which could incorporate XACML as the policy language
>> using OpenAz components. Manifold CF, Qpid and Archiva already have
>> hooks to incorporate external access control systems.
>> >
>> > An Excessive Fascination with the Apache Brand
>> >
>> > We hope that becoming an Apache project will not only attract new
>> participants to OpenAz, but will draw attention to the neglected field
>> of access control. As previously stated it has always been our goal to
>> join Apache, the only question was when the time was ripe.
>> >
>> > Documentation
>> >
>> > The OpenAz web site is:
>> >
>> > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>> >
>> > Java docs can be found here:
>> >
>> >
>> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
>> > index.html
>> >
>> > Initial Source
>> >
>> > The AzAPI, PEPAPI and other related code can be found on sourceforge:
>> >
>> > http://openaz.svn.sourceforge.net/viewvc/openaz/
>> >
>> > AT&T's framework can be found on github:
>> >
>> > https://github.com/att/XACML
>> >
>> > Source and Intellectual Property Submission Plan
>> >
>> > All the OpenAz code has been submitted under the Apache 2.0 license.
>> The AT&T software is available under the MIT license. Over time the
>> project will move to a single license.
>> >
>> > External Dependencies
>> >
>> > There aren't any we are aware of.
>> >
>> > Cryptography
>> >
>> > OpenAz does not provide any cryptographic capabilities. The XACML
>> Standard does specify some uses of cryptography directly, e.g. digital
>> signatures over policies and others by implication, e.g. authentication
>> via cryptography.
>> >
>> > Required Resources
>> >
>> > Mailing lists
>> >
>> > The standard lists should be sufficient at the current time.The
>> mailing list name will be openaz.
>> >
>> > Git Directory
>> >
>> > We propose:
>> > https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>> >
>> > Issue Tracking
>> >
>> > The project will use JIRA for issue tracking.
>> >
>> > Initial Committers
>> >
>> > Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
>> > Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>> >
>> > Affiliations
>> >
>> > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
>> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
>> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>> >
>> > Sponsors
>> >
>> > Champion
>> >
>> > Paul Fremantle
>> >
>> > Nominated Mentors
>> >
>> > Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>> >
>> > Sponsoring Entity
>> >
>> > The Sponsoring Entity will be the Incubator.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

I added a comma and the word "and" to the Mentors section. The Mentors are: 

Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea

Do you see any other formatting errors?

Hal

> -----Original Message-----
> From: Roman Shaposhnik [mailto:roman@shaposhnik.org]
> Sent: Monday, January 05, 2015 1:24 PM
> To: general@incubator.apache.org
> Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
> into the Apache Incubator
> 
> Hi!
> 
> can you please fix the formatting issues? For example, I can't even
> tell the exact list of mentors you're proposing.
> 
> Thanks,
> Roman.
> 
> On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com>
> wrote:
> > I call a vote to accept OpenAz as a new Incubator project.
> >
> > The proposal can be found here:
> > https://wiki.apache.org/incubator/OpenAZProposal
> >
> > and is included below in this email.
> >
> > Voting will remain open until at least January 20, 2015 23:00 ET.
> >
> > Hal Lockhart
> >
> > ---------------------------------------------------------------------
> -
> > -----------------
> >
> > Abstract
> >
> > OpenAz is a project to create tools and libraries to enable the
> development of Attribute-based Access Control (ABAC) Systems in a
> variety of languages. In general the work is at least consistent with
> or actually conformant to the OASIS XACML Standard.
> >
> > Proposal
> >
> > Generally the work falls into two categories: ready to use tools
> which implement standardized or well understood components of an ABAC
> system and design proposals and proof of concept code relating to less
> well understood or experimental aspects of the problem.
> >
> > Much of the work to date has revolved around defining interfaces
> enabling a PEP to request an access control decision from a PDP. The
> XACML standard defines an abstract request format in xml and protocol
> wire formats in xaml and json, but it does not specify programmatic
> interfaces in any language. The standard says that the use of XML (or
> JSON) is not required only the semantic equivalent.
> >
> > The first Interface, AzAPI is modeled closely on the XACML defined
> interface, expressed in Java. One of the goals was to support calls to
> both a PDP local to the same process and a PDP in a remote server.
> AzAPI includes the interface, reference code to handle things like the
> many supported datatypes in XACML and glue code to mate it to the open
> source Sun XACML implementation.
> >
> > Because of the dependence on Sun XACML (which is XACML 2.0) the
> interface was missing some XACML 3.0 features. More recently this was
> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
> done by the JPMC team to support calling a remote PDP. WSo2 is also
> pursuing this capability.
> >
> > A second, higher level interface, PEPAPI was also defined. PEPAPI is
> more intended for application developers with little knowledge of
> XACML. It allows Java objects which contain attribute information to be
> passed in. Conversion methods, called mappers extract information from
> the objects and present it in the format expected by XACML. Some
> implementers have chosen to implement PEPAPI directly against their
> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
> which closely matches the Java one.
> >
> > Examples of more speculative work include: proposals for registration
> and dispatch of Obligation and Advice handlers, a scheme called AMF to
> tell PIPs how to retrieve attributes and PIP code to implement it,
> discussion of PoC code to demonstrate the use of XACML policies to
> drive OAuth interations and a proposal to use XACML policies to express
> OAuth scope.
> >
> > AT&T has recently contributed their extensive XACML framework to the
> project.
> >
> > The AT&T framework represents the entire XACML 3.0 object set as a
> collection of Java interfaces and standard implementations of those
> interfaces. The AT&T PDP engine is built on top of this framework and
> represents a complete implementation of a XACML 3.0 PDP, including all
> of the multi-decision profiles. In addition, the framework also
> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> functionality, allowing application developers to simply annotate a
> Java class to provide attributes for a request. The annotation support
> removes the need for application developers to learn much of the API.
> >
> > The AT&T framework also includes interfaces and implementations to
> standardize development of PIP engines that are used by the AT&T PDP
> implementation, and can be used by other implementations built on top
> of the AT&T framework. The framework also includes interfaces and
> implementations for a PAP distributed cloud infrastructure of PDP nodes
> that includes support for policy distribution and pip configurations.
> This PAP infrastructure includes a web application administrative
> console that contains a XACML 3.0 policy editor, attribute dictionary
> support, and management of PDP RESTful node instances. In addition,
> there are tools available for policy simulation.
> >
> > Background
> >
> > Access Control is in some ways the most basic IT Security service. It
> consists of making a decision about whether a particular request should
> be allowed and enforcing that decision. Aside from schemes like
> permission bits and Access Control Lists (ACLs) the most common way
> access control is implemented is as code in a server or application
> which typically intertwines access control logic with business logic,
> User interface and other software. This makes it difficult to
> understand, modify, analyze or even locate the security policy. The
> primary challenge of Access Control is striking the right balance
> between powerful expression and intelligibility to human beings.
> >
> > The OASIS XACML Standard exemplifies Attribute-Based Access Control
> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
> components. The Policy Enforcement Point (PEP) must be located so as to
> be able to enforce the decision, typically near the resource. The PEP
> first asks the PDP if access should be allowed and provides data, in
> the form of Attributes, to be used as input to the policies held by the
> PDP.
> >
> > In addition to responding permit or deny, XACML allows a policy to
> emit Obligations or Advice, which direct the PEP to do certain things,
> such logging the access or failure or promising to get rid of the data
> after 30 days.
> >
> > Attributes are identified as being in a certain category which
> represents one element in the proposed access. For example attributes
> may be associated with the resource being accessed, the action being
> taken or the environment, .e.g. date/time. Attributes may also be
> associated with any or several types of Subjects, which represent the
> active parties to the access, such as the requester, intermediaries,
> the recipient (if different), the codebase, the machine executing the
> code.
> >
> > Attributes may be provided by the PEP and usually at least a few are,
> but Attributes may also added by other components of the system. It is
> also possible for a PDP to add attributes in the middle of policy
> evaluation. All of these obtain Attributes from the Policy Information
> Point (PIP).
> >
> > The Policy Administration Point (PAP) creates policies and manages
> then through their life cycles and generally the entire infrastructure.
> >
> > The XACML language is essentially a set of expressions which evaluate
> to a Boolean. If true the policy is said to be applicable. The Policy
> contains permit or deny and may include Permissions and or Advice. If
> policies disagree we resolve the conflict with combining algorithms.
> XACML provides some standard ones and you can implement your own.
> Mostly they are common sense like drop non-applicable polices. A
> commonly used algorithm is default deny. Deny overrides permit.
> >
> > Rationale
> >
> > Access Control may be the most basic security service, but for the
> most part it remains primitive in practice. While other services like
> message protection and authentication have seen many advances in recent
> years and decades, deployed access control systems are opaque,
> difficult to us and harder to manage. Most organizations claim that
> they have security policies, protect privacy and accurately report
> financial results, but in practice they have no real way of discovering
> whether their systems actually behave the way they are alleged to do.
> >
> > Just the foreground problems relating to deploying practical ABAC
> systems make a formidable list. If only the PDP knows what the policies
> are, how do we make sure it gets the attributes it needs to evaluate
> policies? How can we name organize, register and dispatch Obligations
> and Advice, allowing handlers to be provided by the system and added by
> users? How can the XACML 3.0 feature of being able to create your own
> attribute categories best be supported by the infrastructure and
> utilized by users? What are the best ways to create and test policies?
> What tools will best help us analyze the effects of the policies in
> force?
> >
> > However, new requirements are rapidly being introduced and need to be
> met. Privacy requirements continue to increase in complexity and scope.
> Data which moves around, such as documents, need to be protected. We
> need secure ways to delegate authority without undermining the
> integrity of the access control system. New applications, business and
> social relationships are driving the need for new policy and delegation
> capabilities.
> >
> > We believe that the way to meet these challenges is to get more
> people actively engaged in using what is currently available so they
> can understand its limitations and make it better. We need to make it
> far easier to get a basic access control infrastructure up and running.
> We need more people who are familiar with XACML the way many people are
> familiar with SQL. If as some people say, XACML is the assembly
> language of access control, we need the real world experience with it
> that will lead us to the useful abstractions that can be implemented in
> higher level languages and other tools.
> >
> > Initial Goals
> >
> > Work is currently underway to extend the PEPAPI and increase its
> flexibility. Since it does not directly correspond to any standard the
> way AzAPI does, it is necessary to struggle with the issues of what to
> expose and what to hide from consumers of the API.
> >
> > Other work in progress involves the architecture of Obligations and
> Advice. There is also an effort to develop a remote client which can
> easily be dropped into any Java environment and make decision requests
> of any commercial or open source XACML PDP.
> >
> > The contribution of AT&T's framework creates a need to integrate the
> prior work with it. Most of the focus will be on AzAPI and the
> corresponding AT&T API, which do largely the same thing. The result is
> likely to be a synthesis, since each has features the other lacks. Then
> PEPAPI will need to be integrated with the new API. The AT&T PDP and
> PAP will be incorporated as is. There has been some parallel work done
> in the area of PIPs. Work will be required to understand how to proceed
> here.
> >
> > Current Status
> >
> > Meritocracy
> >
> > The project was started by Prateek Mishra, Rich Levinson and Hal
> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> Duanhua Tu and Ajith Nair contributed code both using and extending
> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
> Dragosh and Chris Rath contributed the XACML infrastructure they had
> developed at AT&T.
> >
> > During most of its history the project has been very small and has
> made decisions by informal consensus. Major design issues have been
> decided by open debate. Minor issues and experimental proposals have
> been openly welcomed. Several of the participants have a background in
> open consensus-based standards making.
> >
> > In addition to the mailing list, the project has regular phone calls
> every other Thursday.
> >
> > Community
> >
> > The original focus of the project was to attract developers of XACML
> products, either individuals or corporations, and to build alignment
> among vendors on a common API that could simplify technical integration
> for their customers. As OpenAz has matured, our community has grown to
> include application developers working to adopt and deploy XACML in
> their applications. So, for example, contributions reflect what
> individual developers have learned in vertical industries such as
> financial services, healthcare, and computing and communications
> services, and our APIs and internal component architecture have evolved
> to reflect a strong practical understanding of what it takes to deploy
> XACML applications in a large organization.
> >
> > Core Developers
> >
> > The following developers have written most of the code to date.
> >
> > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> > rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> > jpmchase dot com> Chris Rath <car at research dot att dot com>
> Duanhua
> > Tu <duanhua.tu at jpmchase dot com>
> >
> > The following people made other significant technical contributions.
> >
> > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> > <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> > oracle dot com>
> >
> > Alignment
> >
> > It has always been a goal to make OpenAz an Apache project. The
> Apache license was used for all contributions. We believe the project
> has now reached a critical size in terms of developers, organizations
> and contributed code to make it appropriate to make a proposal to the
> Incubator.
> >
> > Known Risks
> >
> > Orphaned Projects
> >
> > Given the small size of the project, there is a risk of the project
> being orphaned. There seems to be strong interest in the use of our
> tools, which should markedly increase with the contribution of the AT&T
> code. "Where can I get an open source PDP?" and "where can I get an
> open source policy editor?" are frequent questions on XACML mailing
> lists.
> >
> > Inexperience with Open Source
> >
> > While few of the developers have extensive experience with open
> source, a number of us have long experience in standards making in open
> consensus-based environments. For example the XACML TC has operated
> since 2001 based on consensus building, with few, if any votes which
> were not unanimous. The main challenge to the project will be managing
> the process with more participants and a more formal process.
> >
> > Homogeneous Developers
> >
> > Currently all the contributors are employees either of companies
> offering an XACML product or large end users deploying XACML technology
> for internal use. The positive aspect is that they are all highly
> experienced senior developers used to operating in a disciplined
> environment. The disadvantage is that the focus to date has mostly been
> problems that arise in large scale environments typified by the
> infrastructure of large corporations.
> >
> > Reliance on Salaried Developers
> >
> > All current committers are salaried developers. However the
> organizations they work for have a long term commitment to the
> technology. We hope that in the Apache foundation we will be able to
> attract new developers to help us address the many fascinating unsolved
> technological problems associated with deploying ABAC.
> >
> > Relationship with other Apache Projects
> >
> > As far as we can determine, no existing Apache project overlaps with
> OpenAz in its goals of the technology developed so far. However, beyond
> the immediate project goals there are many potential opportunities for
> integration with existing Apache projects. Shiro, Turbine and WSS4J are
> Java frameworks which could incorporate XACML as the policy language
> using OpenAz components. Manifold CF, Qpid and Archiva already have
> hooks to incorporate external access control systems.
> >
> > An Excessive Fascination with the Apache Brand
> >
> > We hope that becoming an Apache project will not only attract new
> participants to OpenAz, but will draw attention to the neglected field
> of access control. As previously stated it has always been our goal to
> join Apache, the only question was when the time was ripe.
> >
> > Documentation
> >
> > The OpenAz web site is:
> >
> > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> >
> > Java docs can be found here:
> >
> >
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/
> > index.html
> >
> > Initial Source
> >
> > The AzAPI, PEPAPI and other related code can be found on sourceforge:
> >
> > http://openaz.svn.sourceforge.net/viewvc/openaz/
> >
> > AT&T's framework can be found on github:
> >
> > https://github.com/att/XACML
> >
> > Source and Intellectual Property Submission Plan
> >
> > All the OpenAz code has been submitted under the Apache 2.0 license.
> The AT&T software is available under the MIT license. Over time the
> project will move to a single license.
> >
> > External Dependencies
> >
> > There aren't any we are aware of.
> >
> > Cryptography
> >
> > OpenAz does not provide any cryptographic capabilities. The XACML
> Standard does specify some uses of cryptography directly, e.g. digital
> signatures over policies and others by implication, e.g. authentication
> via cryptography.
> >
> > Required Resources
> >
> > Mailing lists
> >
> > The standard lists should be sufficient at the current time.The
> mailing list name will be openaz.
> >
> > Git Directory
> >
> > We propose:
> > https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
> >
> > Issue Tracking
> >
> > The project will use JIRA for issue tracking.
> >
> > Initial Committers
> >
> > Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> > Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> >
> > Affiliations
> >
> > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> >
> > Sponsors
> >
> > Champion
> >
> > Paul Fremantle
> >
> > Nominated Mentors
> >
> > Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> >
> > Sponsoring Entity
> >
> > The Sponsoring Entity will be the Incubator.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Roman Shaposhnik <ro...@shaposhnik.org>]

Hi!

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

Thanks,
Roman.

On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart <ha...@oracle.com> wrote:
> I call a vote to accept OpenAz as a new Incubator project.
>
> The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal
>
> and is included below in this email.
>
> Voting will remain open until at least January 20, 2015 23:00 ET.
>
> Hal Lockhart
>
> ---------------------------------------------------------------------------------------
>
> Abstract
>
> OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard.
>
> Proposal
>
> Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem.
>
> Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent.
>
> The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation.
>
> Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability.
>
> A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one.
>
> Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope.
>
> AT&T has recently contributed their extensive XACML framework to the project.
>
> The AT&T framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The AT&T PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API.
>
> The AT&T framework also includes interfaces and implementations to standardize development of PIP engines that are used by the AT&T PDP implementation, and can be used by other implementations built on top of the AT&T framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation.
>
> Background
>
> Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface and other software. This makes it difficult to understand, modify, analyze or even locate the security policy. The primary challenge of Access Control is striking the right balance between powerful expression and intelligibility to human beings.
>
> The OASIS XACML Standard exemplifies Attribute-Based Access Control (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other components. The Policy Enforcement Point (PEP) must be located so as to be able to enforce the decision, typically near the resource. The PEP first asks the PDP if access should be allowed and provides data, in the form of Attributes, to be used as input to the policies held by the PDP.
>
> In addition to responding permit or deny, XACML allows a policy to emit Obligations or Advice, which direct the PEP to do certain things, such logging the access or failure or promising to get rid of the data after 30 days.
>
> Attributes are identified as being in a certain category which represents one element in the proposed access. For example attributes may be associated with the resource being accessed, the action being taken or the environment, .e.g. date/time. Attributes may also be associated with any or several types of Subjects, which represent the active parties to the access, such as the requester, intermediaries, the recipient (if different), the codebase, the machine executing the code.
>
> Attributes may be provided by the PEP and usually at least a few are, but Attributes may also added by other components of the system. It is also possible for a PDP to add attributes in the middle of policy evaluation. All of these obtain Attributes from the Policy Information Point (PIP).
>
> The Policy Administration Point (PAP) creates policies and manages then through their life cycles and generally the entire infrastructure.
>
> The XACML language is essentially a set of expressions which evaluate to a Boolean. If true the policy is said to be applicable. The Policy contains permit or deny and may include Permissions and or Advice. If policies disagree we resolve the conflict with combining algorithms. XACML provides some standard ones and you can implement your own. Mostly they are common sense like drop non-applicable polices. A commonly used algorithm is default deny. Deny overrides permit.
>
> Rationale
>
> Access Control may be the most basic security service, but for the most part it remains primitive in practice. While other services like message protection and authentication have seen many advances in recent years and decades, deployed access control systems are opaque, difficult to us and harder to manage. Most organizations claim that they have security policies, protect privacy and accurately report financial results, but in practice they have no real way of discovering whether their systems actually behave the way they are alleged to do.
>
> Just the foreground problems relating to deploying practical ABAC systems make a formidable list. If only the PDP knows what the policies are, how do we make sure it gets the attributes it needs to evaluate policies? How can we name organize, register and dispatch Obligations and Advice, allowing handlers to be provided by the system and added by users? How can the XACML 3.0 feature of being able to create your own attribute categories best be supported by the infrastructure and utilized by users? What are the best ways to create and test policies? What tools will best help us analyze the effects of the policies in force?
>
> However, new requirements are rapidly being introduced and need to be met. Privacy requirements continue to increase in complexity and scope. Data which moves around, such as documents, need to be protected. We need secure ways to delegate authority without undermining the integrity of the access control system. New applications, business and social relationships are driving the need for new policy and delegation capabilities.
>
> We believe that the way to meet these challenges is to get more people actively engaged in using what is currently available so they can understand its limitations and make it better. We need to make it far easier to get a basic access control infrastructure up and running. We need more people who are familiar with XACML the way many people are familiar with SQL. If as some people say, XACML is the assembly language of access control, we need the real world experience with it that will lead us to the useful abstractions that can be implemented in higher level languages and other tools.
>
> Initial Goals
>
> Work is currently underway to extend the PEPAPI and increase its flexibility. Since it does not directly correspond to any standard the way AzAPI does, it is necessary to struggle with the issues of what to expose and what to hide from consumers of the API.
>
> Other work in progress involves the architecture of Obligations and Advice. There is also an effort to develop a remote client which can easily be dropped into any Java environment and make decision requests of any commercial or open source XACML PDP.
>
> The contribution of AT&T's framework creates a need to integrate the prior work with it. Most of the focus will be on AzAPI and the corresponding AT&T API, which do largely the same thing. The result is likely to be a synthesis, since each has features the other lacks. Then PEPAPI will need to be integrated with the new API. The AT&T PDP and PAP will be incorporated as is. There has been some parallel work done in the area of PIPs. Work will be required to understand how to proceed here.
>
> Current Status
>
> Meritocracy
>
> The project was started by Prateek Mishra, Rich Levinson and Hal Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013 Duanhua Tu and Ajith Nair contributed code both using and extending AzAPI and PEPAPI and incorporating PIPs using the AMF as originally proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam Dragosh and Chris Rath contributed the XACML infrastructure they had developed at AT&T.
>
> During most of its history the project has been very small and has made decisions by informal consensus. Major design issues have been decided by open debate. Minor issues and experimental proposals have been openly welcomed. Several of the participants have a background in open consensus-based standards making.
>
> In addition to the mailing list, the project has regular phone calls every other Thursday.
>
> Community
>
> The original focus of the project was to attract developers of XACML products, either individuals or corporations, and to build alignment among vendors on a common API that could simplify technical integration for their customers. As OpenAz has matured, our community has grown to include application developers working to adopt and deploy XACML in their applications. So, for example, contributions reflect what individual developers have learned in vertical industries such as financial services, healthcare, and computing and communications services, and our APIs and internal component architecture have evolved to reflect a strong practical understanding of what it takes to deploy XACML applications in a large organization.
>
> Core Developers
>
> The following developers have written most of the code to date.
>
> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson < rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at jpmchase dot com> Chris Rath <car at research dot att dot com> Duanhua Tu <duanhua.tu at jpmchase dot com>
>
> The following people made other significant technical contributions.
>
> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at oracle dot com>
>
> Alignment
>
> It has always been a goal to make OpenAz an Apache project. The Apache license was used for all contributions. We believe the project has now reached a critical size in terms of developers, organizations and contributed code to make it appropriate to make a proposal to the Incubator.
>
> Known Risks
>
> Orphaned Projects
>
> Given the small size of the project, there is a risk of the project being orphaned. There seems to be strong interest in the use of our tools, which should markedly increase with the contribution of the AT&T code. "Where can I get an open source PDP?" and "where can I get an open source policy editor?" are frequent questions on XACML mailing lists.
>
> Inexperience with Open Source
>
> While few of the developers have extensive experience with open source, a number of us have long experience in standards making in open consensus-based environments. For example the XACML TC has operated since 2001 based on consensus building, with few, if any votes which were not unanimous. The main challenge to the project will be managing the process with more participants and a more formal process.
>
> Homogeneous Developers
>
> Currently all the contributors are employees either of companies offering an XACML product or large end users deploying XACML technology for internal use. The positive aspect is that they are all highly experienced senior developers used to operating in a disciplined environment. The disadvantage is that the focus to date has mostly been problems that arise in large scale environments typified by the infrastructure of large corporations.
>
> Reliance on Salaried Developers
>
> All current committers are salaried developers. However the organizations they work for have a long term commitment to the technology. We hope that in the Apache foundation we will be able to attract new developers to help us address the many fascinating unsolved technological problems associated with deploying ABAC.
>
> Relationship with other Apache Projects
>
> As far as we can determine, no existing Apache project overlaps with OpenAz in its goals of the technology developed so far. However, beyond the immediate project goals there are many potential opportunities for integration with existing Apache projects. Shiro, Turbine and WSS4J are Java frameworks which could incorporate XACML as the policy language using OpenAz components. Manifold CF, Qpid and Archiva already have hooks to incorporate external access control systems.
>
> An Excessive Fascination with the Apache Brand
>
> We hope that becoming an Apache project will not only attract new participants to OpenAz, but will draw attention to the neglected field of access control. As previously stated it has always been our goal to join Apache, the only question was when the time was ripe.
>
> Documentation
>
> The OpenAz web site is:
>
> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>
> Java docs can be found here:
>
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/index.html
>
> Initial Source
>
> The AzAPI, PEPAPI and other related code can be found on sourceforge:
>
> http://openaz.svn.sourceforge.net/viewvc/openaz/
>
> AT&T's framework can be found on github:
>
> https://github.com/att/XACML
>
> Source and Intellectual Property Submission Plan
>
> All the OpenAz code has been submitted under the Apache 2.0 license. The AT&T software is available under the MIT license. Over time the project will move to a single license.
>
> External Dependencies
>
> There aren't any we are aware of.
>
> Cryptography
>
> OpenAz does not provide any cryptographic capabilities. The XACML Standard does specify some uses of cryptography directly, e.g. digital signatures over policies and others by implication, e.g. authentication via cryptography.
>
> Required Resources
>
> Mailing lists
>
> The standard lists should be sufficient at the current time.The mailing list name will be openaz.
>
> Git Directory
>
> We propose: https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
>
> Issue Tracking
>
> The project will use JIRA for issue tracking.
>
> Initial Committers
>
> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu Ajith Nair Srijith Nair Pam Dragosh Chris Rath
>
> Affiliations
>
> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
>
> Sponsors
>
> Champion
>
> Paul Fremantle
>
> Nominated Mentors
>
> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
>
> Sponsoring Entity
>
> The Sponsoring Entity will be the Incubator.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

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

+1

Hal

> -----Original Message-----
> From: Hal Lockhart
> Sent: Monday, January 05, 2015 1:16 PM
> To: general@incubator.apache.org
> Subject: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into
> the Apache Incubator
> 
> I call a vote to accept OpenAz as a new Incubator project.
> 
> The proposal can be found here:
> https://wiki.apache.org/incubator/OpenAZProposal
> 
> and is included below in this email.
> 
> Voting will remain open until at least January 20, 2015 23:00 ET.
> 
> Hal Lockhart
> 
> -----------------------------------------------------------------------
> ----------------
> 
> Abstract
> 
> OpenAz is a project to create tools and libraries to enable the
> development of Attribute-based Access Control (ABAC) Systems in a
> variety of languages. In general the work is at least consistent with
> or actually conformant to the OASIS XACML Standard.
> 
> Proposal
> 
> Generally the work falls into two categories: ready to use tools which
> implement standardized or well understood components of an ABAC system
> and design proposals and proof of concept code relating to less well
> understood or experimental aspects of the problem.
> 
> Much of the work to date has revolved around defining interfaces
> enabling a PEP to request an access control decision from a PDP. The
> XACML standard defines an abstract request format in xml and protocol
> wire formats in xaml and json, but it does not specify programmatic
> interfaces in any language. The standard says that the use of XML (or
> JSON) is not required only the semantic equivalent.
> 
> The first Interface, AzAPI is modeled closely on the XACML defined
> interface, expressed in Java. One of the goals was to support calls to
> both a PDP local to the same process and a PDP in a remote server.
> AzAPI includes the interface, reference code to handle things like the
> many supported datatypes in XACML and glue code to mate it to the open
> source Sun XACML implementation.
> 
> Because of the dependence on Sun XACML (which is XACML 2.0) the
> interface was missing some XACML 3.0 features. More recently this was
> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
> done by the JPMC team to support calling a remote PDP. WSo2 is also
> pursuing this capability.
> 
> A second, higher level interface, PEPAPI was also defined. PEPAPI is
> more intended for application developers with little knowledge of
> XACML. It allows Java objects which contain attribute information to be
> passed in. Conversion methods, called mappers extract information from
> the objects and present it in the format expected by XACML. Some
> implementers have chosen to implement PEPAPI directly against their
> PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
> which closely matches the Java one.
> 
> Examples of more speculative work include: proposals for registration
> and dispatch of Obligation and Advice handlers, a scheme called AMF to
> tell PIPs how to retrieve attributes and PIP code to implement it,
> discussion of PoC code to demonstrate the use of XACML policies to
> drive OAuth interations and a proposal to use XACML policies to express
> OAuth scope.
> 
> AT&T has recently contributed their extensive XACML framework to the
> project.
> 
> The AT&T framework represents the entire XACML 3.0 object set as a
> collection of Java interfaces and standard implementations of those
> interfaces. The AT&T PDP engine is built on top of this framework and
> represents a complete implementation of a XACML 3.0 PDP, including all
> of the multi-decision profiles. In addition, the framework also
> contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
> XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
> functionality, allowing application developers to simply annotate a
> Java class to provide attributes for a request. The annotation support
> removes the need for application developers to learn much of the API.
> 
> The AT&T framework also includes interfaces and implementations to
> standardize development of PIP engines that are used by the AT&T PDP
> implementation, and can be used by other implementations built on top
> of the AT&T framework. The framework also includes interfaces and
> implementations for a PAP distributed cloud infrastructure of PDP nodes
> that includes support for policy distribution and pip configurations.
> This PAP infrastructure includes a web application administrative
> console that contains a XACML 3.0 policy editor, attribute dictionary
> support, and management of PDP RESTful node instances. In addition,
> there are tools available for policy simulation.
> 
> Background
> 
> Access Control is in some ways the most basic IT Security service. It
> consists of making a decision about whether a particular request should
> be allowed and enforcing that decision. Aside from schemes like
> permission bits and Access Control Lists (ACLs) the most common way
> access control is implemented is as code in a server or application
> which typically intertwines access control logic with business logic,
> User interface and other software. This makes it difficult to
> understand, modify, analyze or even locate the security policy. The
> primary challenge of Access Control is striking the right balance
> between powerful expression and intelligibility to human beings.
> 
> The OASIS XACML Standard exemplifies Attribute-Based Access Control
> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
> components. The Policy Enforcement Point (PEP) must be located so as to
> be able to enforce the decision, typically near the resource. The PEP
> first asks the PDP if access should be allowed and provides data, in
> the form of Attributes, to be used as input to the policies held by the
> PDP.
> 
> In addition to responding permit or deny, XACML allows a policy to emit
> Obligations or Advice, which direct the PEP to do certain things, such
> logging the access or failure or promising to get rid of the data after
> 30 days.
> 
> Attributes are identified as being in a certain category which
> represents one element in the proposed access. For example attributes
> may be associated with the resource being accessed, the action being
> taken or the environment, .e.g. date/time. Attributes may also be
> associated with any or several types of Subjects, which represent the
> active parties to the access, such as the requester, intermediaries,
> the recipient (if different), the codebase, the machine executing the
> code.
> 
> Attributes may be provided by the PEP and usually at least a few are,
> but Attributes may also added by other components of the system. It is
> also possible for a PDP to add attributes in the middle of policy
> evaluation. All of these obtain Attributes from the Policy Information
> Point (PIP).
> 
> The Policy Administration Point (PAP) creates policies and manages then
> through their life cycles and generally the entire infrastructure.
> 
> The XACML language is essentially a set of expressions which evaluate
> to a Boolean. If true the policy is said to be applicable. The Policy
> contains permit or deny and may include Permissions and or Advice. If
> policies disagree we resolve the conflict with combining algorithms.
> XACML provides some standard ones and you can implement your own.
> Mostly they are common sense like drop non-applicable polices. A
> commonly used algorithm is default deny. Deny overrides permit.
> 
> Rationale
> 
> Access Control may be the most basic security service, but for the most
> part it remains primitive in practice. While other services like
> message protection and authentication have seen many advances in recent
> years and decades, deployed access control systems are opaque,
> difficult to us and harder to manage. Most organizations claim that
> they have security policies, protect privacy and accurately report
> financial results, but in practice they have no real way of discovering
> whether their systems actually behave the way they are alleged to do.
> 
> Just the foreground problems relating to deploying practical ABAC
> systems make a formidable list. If only the PDP knows what the policies
> are, how do we make sure it gets the attributes it needs to evaluate
> policies? How can we name organize, register and dispatch Obligations
> and Advice, allowing handlers to be provided by the system and added by
> users? How can the XACML 3.0 feature of being able to create your own
> attribute categories best be supported by the infrastructure and
> utilized by users? What are the best ways to create and test policies?
> What tools will best help us analyze the effects of the policies in
> force?
> 
> However, new requirements are rapidly being introduced and need to be
> met. Privacy requirements continue to increase in complexity and scope.
> Data which moves around, such as documents, need to be protected. We
> need secure ways to delegate authority without undermining the
> integrity of the access control system. New applications, business and
> social relationships are driving the need for new policy and delegation
> capabilities.
> 
> We believe that the way to meet these challenges is to get more people
> actively engaged in using what is currently available so they can
> understand its limitations and make it better. We need to make it far
> easier to get a basic access control infrastructure up and running. We
> need more people who are familiar with XACML the way many people are
> familiar with SQL. If as some people say, XACML is the assembly
> language of access control, we need the real world experience with it
> that will lead us to the useful abstractions that can be implemented in
> higher level languages and other tools.
> 
> Initial Goals
> 
> Work is currently underway to extend the PEPAPI and increase its
> flexibility. Since it does not directly correspond to any standard the
> way AzAPI does, it is necessary to struggle with the issues of what to
> expose and what to hide from consumers of the API.
> 
> Other work in progress involves the architecture of Obligations and
> Advice. There is also an effort to develop a remote client which can
> easily be dropped into any Java environment and make decision requests
> of any commercial or open source XACML PDP.
> 
> The contribution of AT&T's framework creates a need to integrate the
> prior work with it. Most of the focus will be on AzAPI and the
> corresponding AT&T API, which do largely the same thing. The result is
> likely to be a synthesis, since each has features the other lacks. Then
> PEPAPI will need to be integrated with the new API. The AT&T PDP and
> PAP will be incorporated as is. There has been some parallel work done
> in the area of PIPs. Work will be required to understand how to proceed
> here.
> 
> Current Status
> 
> Meritocracy
> 
> The project was started by Prateek Mishra, Rich Levinson and Hal
> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI
> code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013
> Duanhua Tu and Ajith Nair contributed code both using and extending
> AzAPI and PEPAPI and incorporating PIPs using the AMF as originally
> proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich
> Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam
> Dragosh and Chris Rath contributed the XACML infrastructure they had
> developed at AT&T.
> 
> During most of its history the project has been very small and has made
> decisions by informal consensus. Major design issues have been decided
> by open debate. Minor issues and experimental proposals have been
> openly welcomed. Several of the participants have a background in open
> consensus-based standards making.
> 
> In addition to the mailing list, the project has regular phone calls
> every other Thursday.
> 
> Community
> 
> The original focus of the project was to attract developers of XACML
> products, either individuals or corporations, and to build alignment
> among vendors on a common API that could simplify technical integration
> for their customers. As OpenAz has matured, our community has grown to
> include application developers working to adopt and deploy XACML in
> their applications. So, for example, contributions reflect what
> individual developers have learned in vertical industries such as
> financial services, healthcare, and computing and communications
> services, and our APIs and internal component architecture have evolved
> to reflect a strong practical understanding of what it takes to deploy
> XACML applications in a large organization.
> 
> Core Developers
> 
> The following developers have written most of the code to date.
> 
> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at
> jpmchase dot com> Chris Rath <car at research dot att dot com> Duanhua
> Tu <duanhua.tu at jpmchase dot com>
> 
> The following people made other significant technical contributions.
> 
> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at
> oracle dot com>
> 
> Alignment
> 
> It has always been a goal to make OpenAz an Apache project. The Apache
> license was used for all contributions. We believe the project has now
> reached a critical size in terms of developers, organizations and
> contributed code to make it appropriate to make a proposal to the
> Incubator.
> 
> Known Risks
> 
> Orphaned Projects
> 
> Given the small size of the project, there is a risk of the project
> being orphaned. There seems to be strong interest in the use of our
> tools, which should markedly increase with the contribution of the AT&T
> code. "Where can I get an open source PDP?" and "where can I get an
> open source policy editor?" are frequent questions on XACML mailing
> lists.
> 
> Inexperience with Open Source
> 
> While few of the developers have extensive experience with open source,
> a number of us have long experience in standards making in open
> consensus-based environments. For example the XACML TC has operated
> since 2001 based on consensus building, with few, if any votes which
> were not unanimous. The main challenge to the project will be managing
> the process with more participants and a more formal process.
> 
> Homogeneous Developers
> 
> Currently all the contributors are employees either of companies
> offering an XACML product or large end users deploying XACML technology
> for internal use. The positive aspect is that they are all highly
> experienced senior developers used to operating in a disciplined
> environment. The disadvantage is that the focus to date has mostly been
> problems that arise in large scale environments typified by the
> infrastructure of large corporations.
> 
> Reliance on Salaried Developers
> 
> All current committers are salaried developers. However the
> organizations they work for have a long term commitment to the
> technology. We hope that in the Apache foundation we will be able to
> attract new developers to help us address the many fascinating unsolved
> technological problems associated with deploying ABAC.
> 
> Relationship with other Apache Projects
> 
> As far as we can determine, no existing Apache project overlaps with
> OpenAz in its goals of the technology developed so far. However, beyond
> the immediate project goals there are many potential opportunities for
> integration with existing Apache projects. Shiro, Turbine and WSS4J are
> Java frameworks which could incorporate XACML as the policy language
> using OpenAz components. Manifold CF, Qpid and Archiva already have
> hooks to incorporate external access control systems.
> 
> An Excessive Fascination with the Apache Brand
> 
> We hope that becoming an Apache project will not only attract new
> participants to OpenAz, but will draw attention to the neglected field
> of access control. As previously stated it has always been our goal to
> join Apache, the only question was when the time was ripe.
> 
> Documentation
> 
> The OpenAz web site is:
> 
> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> 
> Java docs can be found here:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/i
> ndex.html
> 
> Initial Source
> 
> The AzAPI, PEPAPI and other related code can be found on sourceforge:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/
> 
> AT&T's framework can be found on github:
> 
> https://github.com/att/XACML
> 
> Source and Intellectual Property Submission Plan
> 
> All the OpenAz code has been submitted under the Apache 2.0 license.
> The AT&T software is available under the MIT license. Over time the
> project will move to a single license.
> 
> External Dependencies
> 
> There aren't any we are aware of.
> 
> Cryptography
> 
> OpenAz does not provide any cryptographic capabilities. The XACML
> Standard does specify some uses of cryptography directly, e.g. digital
> signatures over policies and others by implication, e.g. authentication
> via cryptography.
> 
> Required Resources
> 
> Mailing lists
> 
> The standard lists should be sufficient at the current time.The mailing
> list name will be openaz.
> 
> Git Directory
> 
> We propose: https://git-wip-us.apache.org/repos/asf/incubator-
> openaz.git
> 
> Issue Tracking
> 
> The project will use JIRA for issue tracking.
> 
> Initial Committers
> 
> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> 
> Affiliations
> 
> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith
> Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> 
> Sponsors
> 
> Champion
> 
> Paul Fremantle
> 
> Nominated Mentors
> 
> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> 
> Sponsoring Entity
> 
> The Sponsoring Entity will be the Incubator.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-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

[VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[jan i <ja...@apache.org>]

+1 binding

have fun
jan i

On Tuesday, January 13, 2015, Alan D. Cabrera <list@toolazydogs.com
<javascript:_e(%7B%7D,'cvml','list@toolazydogs.com');>> wrote:

> +1 binding
>
>
> Regards,
> Alan
>
> > On Jan 5, 2015, at 10:15 AM, Hal Lockhart <ha...@oracle.com>
> wrote:
> >
> > I call a vote to accept OpenAz as a new Incubator project.
> >
> > The proposal can be found here:
> https://wiki.apache.org/incubator/OpenAZProposal
> >
> > and is included below in this email.
> >
> > Voting will remain open until at least January 20, 2015 23:00 ET.
> >
> > Hal Lockhart
> >
> >
> ---------------------------------------------------------------------------------------
> >
> > Abstract
> >
> > OpenAz is a project to create tools and libraries to enable the
> development of Attribute-based Access Control (ABAC) Systems in a variety
> of languages. In general the work is at least consistent with or actually
> conformant to the OASIS XACML Standard.
> >
> > Proposal
> >
> > Generally the work falls into two categories: ready to use tools which
> implement standardized or well understood components of an ABAC system and
> design proposals and proof of concept code relating to less well understood
> or experimental aspects of the problem.
> >
> > Much of the work to date has revolved around defining interfaces
> enabling a PEP to request an access control decision from a PDP. The XACML
> standard defines an abstract request format in xml and protocol wire
> formats in xaml and json, but it does not specify programmatic interfaces
> in any language. The standard says that the use of XML (or JSON) is not
> required only the semantic equivalent.
> >
> > The first Interface, AzAPI is modeled closely on the XACML defined
> interface, expressed in Java. One of the goals was to support calls to both
> a PDP local to the same process and a PDP in a remote server. AzAPI
> includes the interface, reference code to handle things like the many
> supported datatypes in XACML and glue code to mate it to the open source
> Sun XACML implementation.
> >
> > Because of the dependence on Sun XACML (which is XACML 2.0) the
> interface was missing some XACML 3.0 features. More recently this was
> corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done
> by the JPMC team to support calling a remote PDP. WSo2 is also pursuing
> this capability.
> >
> > A second, higher level interface, PEPAPI was also defined. PEPAPI is
> more intended for application developers with little knowledge of XACML. It
> allows Java objects which contain attribute information to be passed in.
> Conversion methods, called mappers extract information from the objects and
> present it in the format expected by XACML. Some implementers have chosen
> to implement PEPAPI directly against their PDP, omitting the use of AzAPI.
> Naomaru Itoi defined a C++ interface which closely matches the Java one.
> >
> > Examples of more speculative work include: proposals for registration
> and dispatch of Obligation and Advice handlers, a scheme called AMF to tell
> PIPs how to retrieve attributes and PIP code to implement it, discussion of
> PoC code to demonstrate the use of XACML policies to drive OAuth
> interations and a proposal to use XACML policies to express OAuth scope.
> >
> > AT&T has recently contributed their extensive XACML framework to the
> project.
> >
> > The AT&T framework represents the entire XACML 3.0 object set as a
> collection of Java interfaces and standard implementations of those
> interfaces. The AT&T PDP engine is built on top of this framework and
> represents a complete implementation of a XACML 3.0 PDP, including all of
> the multi-decision profiles. In addition, the framework also contains an
> implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON
> Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing
> application developers to simply annotate a Java class to provide
> attributes for a request. The annotation support removes the need for
> application developers to learn much of the API.
> >
> > The AT&T framework also includes interfaces and implementations to
> standardize development of PIP engines that are used by the AT&T PDP
> implementation, and can be used by other implementations built on top of
> the AT&T framework. The framework also includes interfaces and
> implementations for a PAP distributed cloud infrastructure of PDP nodes
> that includes support for policy distribution and pip configurations. This
> PAP infrastructure includes a web application administrative console that
> contains a XACML 3.0 policy editor, attribute dictionary support, and
> management of PDP RESTful node instances. In addition, there are tools
> available for policy simulation.
> >
> > Background
> >
> > Access Control is in some ways the most basic IT Security service. It
> consists of making a decision about whether a particular request should be
> allowed and enforcing that decision. Aside from schemes like permission
> bits and Access Control Lists (ACLs) the most common way access control is
> implemented is as code in a server or application which typically
> intertwines access control logic with business logic, User interface and
> other software. This makes it difficult to understand, modify, analyze or
> even locate the security policy. The primary challenge of Access Control is
> striking the right balance between powerful expression and intelligibility
> to human beings.
> >
> > The OASIS XACML Standard exemplifies Attribute-Based Access Control
> (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other
> components. The Policy Enforcement Point (PEP) must be located so as to be
> able to enforce the decision, typically near the resource. The PEP first
> asks the PDP if access should be allowed and provides data, in the form of
> Attributes, to be used as input to the policies held by the PDP.
> >
> > In addition to responding permit or deny, XACML allows a policy to emit
> Obligations or Advice, which direct the PEP to do certain things, such
> logging the access or failure or promising to get rid of the data after 30
> days.
> >
> > Attributes are identified as being in a certain category which
> represents one element in the proposed access. For example attributes may
> be associated with the resource being accessed, the action being taken or
> the environment, .e.g. date/time. Attributes may also be associated with
> any or several types of Subjects, which represent the active parties to the
> access, such as the requester, intermediaries, the recipient (if
> different), the codebase, the machine executing the code.
> >
> > Attributes may be provided by the PEP and usually at least a few are,
> but Attributes may also added by other components of the system. It is also
> possible for a PDP to add attributes in the middle of policy evaluation.
> All of these obtain Attributes from the Policy Information Point (PIP).
> >
> > The Policy Administration Point (PAP) creates policies and manages then
> through their life cycles and generally the entire infrastructure.
> >
> > The XACML language is essentially a set of expressions which evaluate to
> a Boolean. If true the policy is said to be applicable. The Policy contains
> permit or deny and may include Permissions and or Advice. If policies
> disagree we resolve the conflict with combining algorithms. XACML provides
> some standard ones and you can implement your own. Mostly they are common
> sense like drop non-applicable polices. A commonly used algorithm is
> default deny. Deny overrides permit.
> >
> > Rationale
> >
> > Access Control may be the most basic security service, but for the most
> part it remains primitive in practice. While other services like message
> protection and authentication have seen many advances in recent years and
> decades, deployed access control systems are opaque, difficult to us and
> harder to manage. Most organizations claim that they have security
> policies, protect privacy and accurately report financial results, but in
> practice they have no real way of discovering whether their systems
> actually behave the way they are alleged to do.
> >
> > Just the foreground problems relating to deploying practical ABAC
> systems make a formidable list. If only the PDP knows what the policies
> are, how do we make sure it gets the attributes it needs to evaluate
> policies? How can we name organize, register and dispatch Obligations and
> Advice, allowing handlers to be provided by the system and added by users?
> How can the XACML 3.0 feature of being able to create your own attribute
> categories best be supported by the infrastructure and utilized by users?
> What are the best ways to create and test policies? What tools will best
> help us analyze the effects of the policies in force?
> >
> > However, new requirements are rapidly being introduced and need to be
> met. Privacy requirements continue to increase in complexity and scope.
> Data which moves around, such as documents, need to be protected. We need
> secure ways to delegate authority without undermining the integrity of the
> access control system. New applications, business and social relationships
> are driving the need for new policy and delegation capabilities.
> >
> > We believe that the way to meet these challenges is to get more people
> actively engaged in using what is currently available so they can
> understand its limitations and make it better. We need to make it far
> easier to get a basic access control infrastructure up and running. We need
> more people who are familiar with XACML the way many people are familiar
> with SQL. If as some people say, XACML is the assembly language of access
> control, we need the real world experience with it that will lead us to the
> useful abstractions that can be implemented in higher level languages and
> other tools.
> >
> > Initial Goals
> >
> > Work is currently underway to extend the PEPAPI and increase its
> flexibility. Since it does not directly correspond to any standard the way
> AzAPI does, it is necessary to struggle with the issues of what to expose
> and what to hide from consumers of the API.
> >
> > Other work in progress involves the architecture of Obligations and
> Advice. There is also an effort to develop a remote client which can easily
> be dropped into any Java environment and make decision requests of any
> commercial or open source XACML PDP.
> >
> > The contribution of AT&T's framework creates a need to integrate the
> prior work with it. Most of the focus will be on AzAPI and the
> corresponding AT&T API, which do largely the same thing. The result is
> likely to be a synthesis, since each has features the other lacks. Then
> PEPAPI will need to be integrated with the new API. The AT&T PDP and PAP
> will be incorporated as is. There has been some parallel work done in the
> area of PIPs. Work will be required to understand how to proceed here.
> >
> > Current Status
> >
> > Meritocracy
> >
> > The project was started by Prateek Mishra, Rich Levinson and Hal
> Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI code.
> Naomaru Itoi defined the C++ version of the PEPAPI. In 2013 Duanhua Tu and
> Ajith Nair contributed code both using and extending AzAPI and PEPAPI and
> incorporating PIPs using the AMF as originally proposed by Hal Lockhart. In
> 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated AzAPI to include
> all XACML 3.0 features. In 2014 Pam Dragosh and Chris Rath contributed the
> XACML infrastructure they had developed at AT&T.
> >
> > During most of its history the project has been very small and has made
> decisions by informal consensus. Major design issues have been decided by
> open debate. Minor issues and experimental proposals have been openly
> welcomed. Several of the participants have a background in open
> consensus-based standards making.
> >
> > In addition to the mailing list, the project has regular phone calls
> every other Thursday.
> >
> > Community
> >
> > The original focus of the project was to attract developers of XACML
> products, either individuals or corporations, and to build alignment among
> vendors on a common API that could simplify technical integration for their
> customers. As OpenAz has matured, our community has grown to include
> application developers working to adopt and deploy XACML in their
> applications. So, for example, contributions reflect what individual
> developers have learned in vertical industries such as financial services,
> healthcare, and computing and communications services, and our APIs and
> internal component architecture have evolved to reflect a strong practical
> understanding of what it takes to deploy XACML applications in a large
> organization.
> >
> > Core Developers
> >
> > The following developers have written most of the code to date.
> >
> > Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson <
> rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at jpmchase
> dot com> Chris Rath <car at research dot att dot com> Duanhua Tu
> <duanhua.tu at jpmchase dot com>
> >
> > The following people made other significant technical contributions.
> >
> > David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart
> <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at oracle
> dot com>
> >
> > Alignment
> >
> > It has always been a goal to make OpenAz an Apache project. The Apache
> license was used for all contributions. We believe the project has now
> reached a critical size in terms of developers, organizations and
> contributed code to make it appropriate to make a proposal to the Incubator.
> >
> > Known Risks
> >
> > Orphaned Projects
> >
> > Given the small size of the project, there is a risk of the project
> being orphaned. There seems to be strong interest in the use of our tools,
> which should markedly increase with the contribution of the AT&T code.
> "Where can I get an open source PDP?" and "where can I get an open source
> policy editor?" are frequent questions on XACML mailing lists.
> >
> > Inexperience with Open Source
> >
> > While few of the developers have extensive experience with open source,
> a number of us have long experience in standards making in open
> consensus-based environments. For example the XACML TC has operated since
> 2001 based on consensus building, with few, if any votes which were not
> unanimous. The main challenge to the project will be managing the process
> with more participants and a more formal process.
> >
> > Homogeneous Developers
> >
> > Currently all the contributors are employees either of companies
> offering an XACML product or large end users deploying XACML technology for
> internal use. The positive aspect is that they are all highly experienced
> senior developers used to operating in a disciplined environment. The
> disadvantage is that the focus to date has mostly been problems that arise
> in large scale environments typified by the infrastructure of large
> corporations.
> >
> > Reliance on Salaried Developers
> >
> > All current committers are salaried developers. However the
> organizations they work for have a long term commitment to the technology.
> We hope that in the Apache foundation we will be able to attract new
> developers to help us address the many fascinating unsolved technological
> problems associated with deploying ABAC.
> >
> > Relationship with other Apache Projects
> >
> > As far as we can determine, no existing Apache project overlaps with
> OpenAz in its goals of the technology developed so far. However, beyond the
> immediate project goals there are many potential opportunities for
> integration with existing Apache projects. Shiro, Turbine and WSS4J are
> Java frameworks which could incorporate XACML as the policy language using
> OpenAz components. Manifold CF, Qpid and Archiva already have hooks to
> incorporate external access control systems.
> >
> > An Excessive Fascination with the Apache Brand
> >
> > We hope that becoming an Apache project will not only attract new
> participants to OpenAz, but will draw attention to the neglected field of
> access control. As previously stated it has always been our goal to join
> Apache, the only question was when the time was ripe.
> >
> > Documentation
> >
> > The OpenAz web site is:
> >
> > http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> >
> > Java docs can be found here:
> >
> >
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/index.html
> >
> > Initial Source
> >
> > The AzAPI, PEPAPI and other related code can be found on sourceforge:
> >
> > http://openaz.svn.sourceforge.net/viewvc/openaz/
> >
> > AT&T's framework can be found on github:
> >
> > https://github.com/att/XACML
> >
> > Source and Intellectual Property Submission Plan
> >
> > All the OpenAz code has been submitted under the Apache 2.0 license. The
> AT&T software is available under the MIT license. Over time the project
> will move to a single license.
> >
> > External Dependencies
> >
> > There aren't any we are aware of.
> >
> > Cryptography
> >
> > OpenAz does not provide any cryptographic capabilities. The XACML
> Standard does specify some uses of cryptography directly, e.g. digital
> signatures over policies and others by implication, e.g. authentication via
> cryptography.
> >
> > Required Resources
> >
> > Mailing lists
> >
> > The standard lists should be sufficient at the current time.The mailing
> list name will be openaz.
> >
> > Git Directory
> >
> > We propose: https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
> >
> > Issue Tracking
> >
> > The project will use JIRA for issue tracking.
> >
> > Initial Committers
> >
> > Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu
> Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> >
> > Affiliations
> >
> > Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David
> Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith Nair
> works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> >
> > Sponsors
> >
> > Champion
> >
> > Paul Fremantle
> >
> > Nominated Mentors
> >
> > Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> >
> > Sponsoring Entity
> >
> > The Sponsoring Entity will be the Incubator.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-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
>
>

-- 
Sent from My iPad, sorry for any misspellings.

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

["Alan D. Cabrera" <li...@toolazydogs.com>]

+1 binding


Regards,
Alan

> On Jan 5, 2015, at 10:15 AM, Hal Lockhart <ha...@oracle.com> wrote:
> 
> I call a vote to accept OpenAz as a new Incubator project.
> 
> The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal
> 
> and is included below in this email.
> 
> Voting will remain open until at least January 20, 2015 23:00 ET.
> 
> Hal Lockhart
> 
> ---------------------------------------------------------------------------------------
> 
> Abstract
> 
> OpenAz is a project to create tools and libraries to enable the development of Attribute-based Access Control (ABAC) Systems in a variety of languages. In general the work is at least consistent with or actually conformant to the OASIS XACML Standard.
> 
> Proposal
> 
> Generally the work falls into two categories: ready to use tools which implement standardized or well understood components of an ABAC system and design proposals and proof of concept code relating to less well understood or experimental aspects of the problem.
> 
> Much of the work to date has revolved around defining interfaces enabling a PEP to request an access control decision from a PDP. The XACML standard defines an abstract request format in xml and protocol wire formats in xaml and json, but it does not specify programmatic interfaces in any language. The standard says that the use of XML (or JSON) is not required only the semantic equivalent.
> 
> The first Interface, AzAPI is modeled closely on the XACML defined interface, expressed in Java. One of the goals was to support calls to both a PDP local to the same process and a PDP in a remote server. AzAPI includes the interface, reference code to handle things like the many supported datatypes in XACML and glue code to mate it to the open source Sun XACML implementation.
> 
> Because of the dependence on Sun XACML (which is XACML 2.0) the interface was missing some XACML 3.0 features. More recently this was corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support calling a remote PDP. WSo2 is also pursuing this capability.
> 
> A second, higher level interface, PEPAPI was also defined. PEPAPI is more intended for application developers with little knowledge of XACML. It allows Java objects which contain attribute information to be passed in. Conversion methods, called mappers extract information from the objects and present it in the format expected by XACML. Some implementers have chosen to implement PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface which closely matches the Java one.
> 
> Examples of more speculative work include: proposals for registration and dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs how to retrieve attributes and PIP code to implement it, discussion of PoC code to demonstrate the use of XACML policies to drive OAuth interations and a proposal to use XACML policies to express OAuth scope.
> 
> AT&T has recently contributed their extensive XACML framework to the project.
> 
> The AT&T framework represents the entire XACML 3.0 object set as a collection of Java interfaces and standard implementations of those interfaces. The AT&T PDP engine is built on top of this framework and represents a complete implementation of a XACML 3.0 PDP, including all of the multi-decision profiles. In addition, the framework also contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API includes annotation functionality, allowing application developers to simply annotate a Java class to provide attributes for a request. The annotation support removes the need for application developers to learn much of the API.
> 
> The AT&T framework also includes interfaces and implementations to standardize development of PIP engines that are used by the AT&T PDP implementation, and can be used by other implementations built on top of the AT&T framework. The framework also includes interfaces and implementations for a PAP distributed cloud infrastructure of PDP nodes that includes support for policy distribution and pip configurations. This PAP infrastructure includes a web application administrative console that contains a XACML 3.0 policy editor, attribute dictionary support, and management of PDP RESTful node instances. In addition, there are tools available for policy simulation.
> 
> Background
> 
> Access Control is in some ways the most basic IT Security service. It consists of making a decision about whether a particular request should be allowed and enforcing that decision. Aside from schemes like permission bits and Access Control Lists (ACLs) the most common way access control is implemented is as code in a server or application which typically intertwines access control logic with business logic, User interface and other software. This makes it difficult to understand, modify, analyze or even locate the security policy. The primary challenge of Access Control is striking the right balance between powerful expression and intelligibility to human beings.
> 
> The OASIS XACML Standard exemplifies Attribute-Based Access Control (ABAC). In ABAC, the Policy Decision Point (PDP) is isolated from other components. The Policy Enforcement Point (PEP) must be located so as to be able to enforce the decision, typically near the resource. The PEP first asks the PDP if access should be allowed and provides data, in the form of Attributes, to be used as input to the policies held by the PDP.
> 
> In addition to responding permit or deny, XACML allows a policy to emit Obligations or Advice, which direct the PEP to do certain things, such logging the access or failure or promising to get rid of the data after 30 days.
> 
> Attributes are identified as being in a certain category which represents one element in the proposed access. For example attributes may be associated with the resource being accessed, the action being taken or the environment, .e.g. date/time. Attributes may also be associated with any or several types of Subjects, which represent the active parties to the access, such as the requester, intermediaries, the recipient (if different), the codebase, the machine executing the code.
> 
> Attributes may be provided by the PEP and usually at least a few are, but Attributes may also added by other components of the system. It is also possible for a PDP to add attributes in the middle of policy evaluation. All of these obtain Attributes from the Policy Information Point (PIP).
> 
> The Policy Administration Point (PAP) creates policies and manages then through their life cycles and generally the entire infrastructure.
> 
> The XACML language is essentially a set of expressions which evaluate to a Boolean. If true the policy is said to be applicable. The Policy contains permit or deny and may include Permissions and or Advice. If policies disagree we resolve the conflict with combining algorithms. XACML provides some standard ones and you can implement your own. Mostly they are common sense like drop non-applicable polices. A commonly used algorithm is default deny. Deny overrides permit.
> 
> Rationale
> 
> Access Control may be the most basic security service, but for the most part it remains primitive in practice. While other services like message protection and authentication have seen many advances in recent years and decades, deployed access control systems are opaque, difficult to us and harder to manage. Most organizations claim that they have security policies, protect privacy and accurately report financial results, but in practice they have no real way of discovering whether their systems actually behave the way they are alleged to do.
> 
> Just the foreground problems relating to deploying practical ABAC systems make a formidable list. If only the PDP knows what the policies are, how do we make sure it gets the attributes it needs to evaluate policies? How can we name organize, register and dispatch Obligations and Advice, allowing handlers to be provided by the system and added by users? How can the XACML 3.0 feature of being able to create your own attribute categories best be supported by the infrastructure and utilized by users? What are the best ways to create and test policies? What tools will best help us analyze the effects of the policies in force?
> 
> However, new requirements are rapidly being introduced and need to be met. Privacy requirements continue to increase in complexity and scope. Data which moves around, such as documents, need to be protected. We need secure ways to delegate authority without undermining the integrity of the access control system. New applications, business and social relationships are driving the need for new policy and delegation capabilities.
> 
> We believe that the way to meet these challenges is to get more people actively engaged in using what is currently available so they can understand its limitations and make it better. We need to make it far easier to get a basic access control infrastructure up and running. We need more people who are familiar with XACML the way many people are familiar with SQL. If as some people say, XACML is the assembly language of access control, we need the real world experience with it that will lead us to the useful abstractions that can be implemented in higher level languages and other tools.
> 
> Initial Goals
> 
> Work is currently underway to extend the PEPAPI and increase its flexibility. Since it does not directly correspond to any standard the way AzAPI does, it is necessary to struggle with the issues of what to expose and what to hide from consumers of the API.
> 
> Other work in progress involves the architecture of Obligations and Advice. There is also an effort to develop a remote client which can easily be dropped into any Java environment and make decision requests of any commercial or open source XACML PDP.
> 
> The contribution of AT&T's framework creates a need to integrate the prior work with it. Most of the focus will be on AzAPI and the corresponding AT&T API, which do largely the same thing. The result is likely to be a synthesis, since each has features the other lacks. Then PEPAPI will need to be integrated with the new API. The AT&T PDP and PAP will be incorporated as is. There has been some parallel work done in the area of PIPs. Work will be required to understand how to proceed here.
> 
> Current Status
> 
> Meritocracy
> 
> The project was started by Prateek Mishra, Rich Levinson and Hal Lockhart in 2010. Rich Levinson wrote most of the AzAPI and PEPAPI code. Naomaru Itoi defined the C++ version of the PEPAPI. In 2013 Duanhua Tu and Ajith Nair contributed code both using and extending AzAPI and PEPAPI and incorporating PIPs using the AMF as originally proposed by Hal Lockhart. In 2013 Erik Rissanen, Srijith Nair and Rich Levinson updated AzAPI to include all XACML 3.0 features. In 2014 Pam Dragosh and Chris Rath contributed the XACML infrastructure they had developed at AT&T.
> 
> During most of its history the project has been very small and has made decisions by informal consensus. Major design issues have been decided by open debate. Minor issues and experimental proposals have been openly welcomed. Several of the participants have a background in open consensus-based standards making.
> 
> In addition to the mailing list, the project has regular phone calls every other Thursday.
> 
> Community
> 
> The original focus of the project was to attract developers of XACML products, either individuals or corporations, and to build alignment among vendors on a common API that could simplify technical integration for their customers. As OpenAz has matured, our community has grown to include application developers working to adopt and deploy XACML in their applications. So, for example, contributions reflect what individual developers have learned in vertical industries such as financial services, healthcare, and computing and communications services, and our APIs and internal component architecture have evolved to reflect a strong practical understanding of what it takes to deploy XACML applications in a large organization.
> 
> Core Developers
> 
> The following developers have written most of the code to date.
> 
> Pam Dragosh <pdragosh at research dot att dot com> Rich Levinson < rich.levinson at oracle dot com> Ajith Nair <ajithkumar.r.nair at jpmchase dot com> Chris Rath <car at research dot att dot com> Duanhua Tu <duanhua.tu at jpmchase dot com>
> 
> The following people made other significant technical contributions.
> 
> David Laurence <david.c.laurance at jpmorgan dot com> Hal Lockhart <hal.lockhart at oracle dot com> Prateek Mishra prateek.mishra at oracle dot com>
> 
> Alignment
> 
> It has always been a goal to make OpenAz an Apache project. The Apache license was used for all contributions. We believe the project has now reached a critical size in terms of developers, organizations and contributed code to make it appropriate to make a proposal to the Incubator.
> 
> Known Risks
> 
> Orphaned Projects
> 
> Given the small size of the project, there is a risk of the project being orphaned. There seems to be strong interest in the use of our tools, which should markedly increase with the contribution of the AT&T code. "Where can I get an open source PDP?" and "where can I get an open source policy editor?" are frequent questions on XACML mailing lists.
> 
> Inexperience with Open Source
> 
> While few of the developers have extensive experience with open source, a number of us have long experience in standards making in open consensus-based environments. For example the XACML TC has operated since 2001 based on consensus building, with few, if any votes which were not unanimous. The main challenge to the project will be managing the process with more participants and a more formal process.
> 
> Homogeneous Developers
> 
> Currently all the contributors are employees either of companies offering an XACML product or large end users deploying XACML technology for internal use. The positive aspect is that they are all highly experienced senior developers used to operating in a disciplined environment. The disadvantage is that the focus to date has mostly been problems that arise in large scale environments typified by the infrastructure of large corporations.
> 
> Reliance on Salaried Developers
> 
> All current committers are salaried developers. However the organizations they work for have a long term commitment to the technology. We hope that in the Apache foundation we will be able to attract new developers to help us address the many fascinating unsolved technological problems associated with deploying ABAC.
> 
> Relationship with other Apache Projects
> 
> As far as we can determine, no existing Apache project overlaps with OpenAz in its goals of the technology developed so far. However, beyond the immediate project goals there are many potential opportunities for integration with existing Apache projects. Shiro, Turbine and WSS4J are Java frameworks which could incorporate XACML as the policy language using OpenAz components. Manifold CF, Qpid and Archiva already have hooks to incorporate external access control systems.
> 
> An Excessive Fascination with the Apache Brand
> 
> We hope that becoming an Apache project will not only attract new participants to OpenAz, but will draw attention to the neglected field of access control. As previously stated it has always been our goal to join Apache, the only question was when the time was ripe.
> 
> Documentation
> 
> The OpenAz web site is:
> 
> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
> 
> Java docs can be found here:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/index.html
> 
> Initial Source
> 
> The AzAPI, PEPAPI and other related code can be found on sourceforge:
> 
> http://openaz.svn.sourceforge.net/viewvc/openaz/
> 
> AT&T's framework can be found on github:
> 
> https://github.com/att/XACML
> 
> Source and Intellectual Property Submission Plan
> 
> All the OpenAz code has been submitted under the Apache 2.0 license. The AT&T software is available under the MIT license. Over time the project will move to a single license.
> 
> External Dependencies
> 
> There aren't any we are aware of.
> 
> Cryptography
> 
> OpenAz does not provide any cryptographic capabilities. The XACML Standard does specify some uses of cryptography directly, e.g. digital signatures over policies and others by implication, e.g. authentication via cryptography.
> 
> Required Resources
> 
> Mailing lists
> 
> The standard lists should be sufficient at the current time.The mailing list name will be openaz.
> 
> Git Directory
> 
> We propose: https://git-wip-us.apache.org/repos/asf/incubator-openaz.git
> 
> Issue Tracking
> 
> The project will use JIRA for issue tracking.
> 
> Initial Committers
> 
> Rich Levinson Hal Lockhart Prateek Mishra David Laurance Duanhua Tu Ajith Nair Srijith Nair Pam Dragosh Chris Rath
> 
> Affiliations
> 
> Rich Levinson, Hal Lockhart and Prateek Mishra work for Oracle. David Laurance, Duanhua Tu and Ajith Nair work for JP Morgan-Chase. Srijith Nair works for Axiomatics. Pam Dragosh and Chris Rath work for AT&T.
> 
> Sponsors
> 
> Champion
> 
> Paul Fremantle
> 
> Nominated Mentors
> 
> Emmanuel Lécharny Colm O hEigeartaigh Hadrian Zbarcea
> 
> Sponsoring Entity
> 
> The Sponsoring Entity will be the Incubator.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-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: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Emmanuel Lécharny <el...@gmail.com>]

+1

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