[RESULT] [VOTE] Accept OpenAz (Access Control Tools) into the Apache Incubator
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 i
RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
+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. > >
RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
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:ro...@shaposhnik.org] > Sent: Monday, January 05, 2015 1:24 PM > To: general@incubator.apache.org > Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) > into the Apache Incubator > > Hi! > > can you please fix the formatting issues? For example, I can't even > tell the exact list of mentors you're proposing. > > Thanks, > Roman. > > On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart > 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 > standar
[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
Need an additional Mentor for the OpenAz Project
The OpenAz Project currently has two mentors, but we need at least one more. Is there anyone who would be willing to join us? The proposal is here: https://wiki.apache.org/incubator/OpenAZProposal Thanks in advance, Hal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [PROPOSAL] OpenAZ as new Incubator project
My apologies. Hal > -Original Message- > From: Colm O hEigeartaigh [mailto:cohei...@apache.org] > Sent: Friday, November 14, 2014 11:10 AM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > It will be cool to see a XACML project at Apache, especially one that > looks certain to be the main open source implementation. One minor > correction: > > > Colm MacCárthaigh > > You have the wrong Apache Colm there :-) > > Colm (O hEigeartaigh) > > On Fri, Nov 14, 2014 at 1:55 PM, Hal Lockhart > wrote: > > > I was not questioning whether to initiate discussion. That was what I > > was trying to do. > > > > I was asking how to go about it. > > > > Thanks for the comments, they are noted. > > > > Hal > > > > > -Original Message- > > > From: John D. Ament [mailto:john.d.am...@gmail.com] > > > Sent: Thursday, November 13, 2014 8:59 PM > > > To: general@incubator.apache.org > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > > > > > I think so. > > > > > > There's a few things that you want to iron out first, before people > > > start voting on this. > > > > > > - 3 is generally the "minimum" number of mentors. > > > - I can't find a "Paul Freemantle" on the apache committers list. > > > There's a Paul Fremantle, minor spelling difference. > > > - You may want to review this section to get a better understanding > > > of the > > > goals: http://incubator.apache.org/guides/proposal.html#formulating > > > > > > the Discuss option just helps everyone look at your proposal a > > > little bit better and determine if there's any gotchas. For > > > example, I'm surprised to see a new incubator project using SVN. > > > > > > - Can you list out your issue tracking preference (should probably > > > be JIRA unless you need something else) > > > - Please also explicitly list the mailing lists your want. > > > > > > John > > > > > > On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart > > > > > > wrote: > > > > > > > So you want me to repost the proposal with the Subject changed to > > > > start with "[DISCUSS]"? Or should I simply reference the wiki > page? > > > > > > > > Hal > > > > > > > > > -Original Message- > > > > > From: John D. Ament [mailto:john.d.am...@gmail.com] > > > > > Sent: Thursday, November 13, 2014 5:03 PM > > > > > To: general@incubator.apache.org > > > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > > > > > > > > > Hal, > > > > > > > > > > Per customs, would you mind if we cancel this and start with a > > > > > [DISCUSS] thread about OpenAZ? It's unclear if you meant this > > > > > to > > > be > > > > > a vote or something. > > > > > > > > > > John > > > > > > > > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > > > > > > > > > > wrote: > > > > > > > > > > > Abstract > > > > > > > > > > > > OpenAz is a project to create tools and libraries to enable > > > > > > the development of Attribute-based Access Control (ABAC) > > > > > > Systems in a variety of languages. In general the work is at > > > > > > least consistent with or actually conformant to the OASIS > XACML Standard. > > > > > > > > > > > > Proposal > > > > > > > > > > > > Generally the work falls into two categories: ready to use > > > > > > tools > > > > > which > > > > > > implement standardized or well understood components of an > > > > > > ABAC > > > > > system > > > > > > and design proposals and proof of concept code relating to > > > > > > less well understood or experimental aspects of the problem. > > > > > > > > > > > > Much of the work to date has revolved around defining > > > > > > interfaces enabling a PEP to request an access control > decision from a PDP. > > > > > > The XACML standard defines an abstract request format in xml > > > > > &g
RE: [PROPOSAL] OpenAZ as new Incubator project
I was not questioning whether to initiate discussion. That was what I was trying to do. I was asking how to go about it. Thanks for the comments, they are noted. Hal > -Original Message- > From: John D. Ament [mailto:john.d.am...@gmail.com] > Sent: Thursday, November 13, 2014 8:59 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > I think so. > > There's a few things that you want to iron out first, before people > start voting on this. > > - 3 is generally the "minimum" number of mentors. > - I can't find a "Paul Freemantle" on the apache committers list. > There's a Paul Fremantle, minor spelling difference. > - You may want to review this section to get a better understanding of > the > goals: http://incubator.apache.org/guides/proposal.html#formulating > > the Discuss option just helps everyone look at your proposal a little > bit better and determine if there's any gotchas. For example, I'm > surprised to see a new incubator project using SVN. > > - Can you list out your issue tracking preference (should probably be > JIRA unless you need something else) > - Please also explicitly list the mailing lists your want. > > John > > On Thu, Nov 13, 2014 at 8:43 PM, Hal Lockhart > wrote: > > > So you want me to repost the proposal with the Subject changed to > > start with "[DISCUSS]"? Or should I simply reference the wiki page? > > > > Hal > > > > > -Original Message- > > > From: John D. Ament [mailto:john.d.am...@gmail.com] > > > Sent: Thursday, November 13, 2014 5:03 PM > > > To: general@incubator.apache.org > > > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > > > > > Hal, > > > > > > Per customs, would you mind if we cancel this and start with a > > > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to > be > > > a vote or something. > > > > > > John > > > > > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > > > > > > wrote: > > > > > > > Abstract > > > > > > > > OpenAz is a project to create tools and libraries to enable the > > > > development of Attribute-based Access Control (ABAC) Systems in a > > > > variety of languages. In general the work is at least consistent > > > > with or actually conformant to the OASIS XACML Standard. > > > > > > > > Proposal > > > > > > > > Generally the work falls into two categories: ready to use tools > > > which > > > > implement standardized or well understood components of an ABAC > > > system > > > > and design proposals and proof of concept code relating to less > > > > well understood or experimental aspects of the problem. > > > > > > > > Much of the work to date has revolved around defining interfaces > > > > enabling a PEP to request an access control decision from a PDP. > > > > The XACML standard defines an abstract request format in xml and > > > > protocol wire formats in xaml and json, but it does not specify > > > > programmatic > > > interfaces in any language. > > > > The standard says that the use of XML (or JSON) is not required > > > > only the semantics equivalent. > > > > > > > > The first Interface, AzAPI is modeled closely on the XACML > defined > > > > interface, expressed in Java. One of the goals was to support > > > > calls > > > to > > > > both a PDP local to the same process and a PDP in a remote > server. > > > > AzAPI includes the interface, reference code to handle things > like > > > the > > > > many supported datatypes in XACML and glue code to mate it to the > > > open > > > > source Sun XACML implementation. > > > > > > > > Because of the dependence on Sun XACML (which is XACML 2.0) the > > > > interface was missing some XACML 3.0 features. More recently this > > > > was corrected and > > > > WSo2 has mated it to their XACML 3.0 PDP. Some work was done by > > > > the JPMC team to support calling a remote PDP. WSo2 is also > > > > pursuing this > > > capability. > > > > > > > > A second, higher level interface, PEPAPI was also defined. PEPAPI > > > > is more intended for application developers with little knowledge > > > > of XACML. It a
[DISCUSS] OpenAZ as new Incubator project
rk 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 Rich Levinson < rich.levinson at oracle dot com> Ajith Nair Chris Rath Duanhua Tu The following people made other significant technical contributions. David Laurence Hal Lockhart 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
RE: [PROPOSAL] OpenAZ as new Incubator project
So you want me to repost the proposal with the Subject changed to start with "[DISCUSS]"? Or should I simply reference the wiki page? Hal > -Original Message- > From: John D. Ament [mailto:john.d.am...@gmail.com] > Sent: Thursday, November 13, 2014 5:03 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Hal, > > Per customs, would you mind if we cancel this and start with a > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a > vote or something. > > John > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > wrote: > > > Abstract > > > > OpenAz is a project to create tools and libraries to enable the > > development of Attribute-based Access Control (ABAC) Systems in a > > variety of languages. In general the work is at least consistent with > > or actually conformant to the OASIS XACML Standard. > > > > Proposal > > > > Generally the work falls into two categories: ready to use tools > which > > implement standardized or well understood components of an ABAC > system > > and design proposals and proof of concept code relating to less well > > understood or experimental aspects of the problem. > > > > Much of the work to date has revolved around defining interfaces > > enabling a PEP to request an access control decision from a PDP. The > > XACML standard defines an abstract request format in xml and protocol > > wire formats in xaml and json, but it does not specify programmatic > interfaces in any language. > > The standard says that the use of XML (or JSON) is not required only > > the semantics equivalent. > > > > The first Interface, AzAPI is modeled closely on the XACML defined > > interface, expressed in Java. One of the goals was to support calls > to > > both a PDP local to the same process and a PDP in a remote server. > > AzAPI includes the interface, reference code to handle things like > the > > many supported datatypes in XACML and glue code to mate it to the > open > > source Sun XACML implementation. > > > > Because of the dependence on Sun XACML (which is XACML 2.0) the > > interface was missing some XACML 3.0 features. More recently this was > > corrected and > > WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the > > JPMC team to support calling a remote PDP. WSo2 is also pursuing this > capability. > > > > A second, higher level interface, PEPAPI was also defined. PEPAPI is > > more intended for application developers with little knowledge of > > XACML. It allows Java objects which contain attribute information to > be passed in. > > Conversion methods, called mappers extract information from the > > objects and present it in the format expected by XACML. Some > > implementers have chosen to implement PEPAPI directly against their > PDP, omitting the use of AzAPI. > > Naomaru Itoi defined a C++ interface which closely matches the Java > one. > > > > Examples of more speculative work include: proposals for registration > > and dispatch of Obligation and Advice handlers, a scheme called AMF > to > > tell PIPs how to retrieve attributes and PIP code to implement it, > > discussion of PoC code to demonstrate the use of XACML policies to > > drive OAuth interations and a proposal to use XACML policies to > express OAuth scope. > > > > AT&T has recently contributed their extensive XACML framework to the > > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > > collection of Java interfaces and standard implementations of those > > interfaces. The AT&T PDP engine is built on top of this framework > and > > represents a complete implementation of a XACML 3.0 PDP, including > all > > of the multi-decision profiles. In addition, the framework also > > contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 > and > > XACML JSON Profile v1.0 WD 14. The PEP API includes annotation > > functionality, allowing application developers to simply annotate a > > Java class to provide attributes for a request. The annotation > support > > removes the need for application developers to learn much of the API. > > > > The AT&T framework also includes interfaces and implementations to > > standardize development of PIP engines that are used by the AT&T PDP > > implementation, and can be used by other implementations built on top > > of the AT&T framework. The framework also includes interfaces and > > implementations for a PAP distribu
RE: [PROPOSAL] OpenAZ as new Incubator project
Did you see the background section? I meant that to provide that information. I was unclear on how much to assume the audience already knows about the subject. Hal > -Original Message- > From: Henry Saputra [mailto:henry.sapu...@gmail.com] > Sent: Thursday, November 13, 2014 4:31 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Could you add more description on what is PEP and PDP and other > acronyms used in the proposal? If it is not directly relevant maybe you > can rephrase it to more generic analogy. > > Thanks, > > Henry > > On Thu, Nov 13, 2014 at 1:14 PM, Hal Lockhart > wrote: > > Abstract > > > > OpenAz is a project to create tools and libraries to enable the > development of Attribute-based Access Control (ABAC) Systems in a > variety of languages. In general the work is at least consistent with > or actually conformant to the OASIS XACML Standard. > > > > Proposal > > > > Generally the work falls into two categories: ready to use tools > which implement standardized or well understood components of an ABAC > system and design proposals and proof of concept code relating to less > well understood or experimental aspects of the problem. > > > > Much of the work to date has revolved around defining interfaces > enabling a PEP to request an access control decision from a PDP. The > XACML standard defines an abstract request format in xml and protocol > wire formats in xaml and json, but it does not specify programmatic > interfaces in any language. The standard says that the use of XML (or > JSON) is not required only the semantics equivalent. > > > > The first Interface, AzAPI is modeled closely on the XACML defined > interface, expressed in Java. One of the goals was to support calls to > both a PDP local to the same process and a PDP in a remote server. > AzAPI includes the interface, reference code to handle things like the > many supported datatypes in XACML and glue code to mate it to the open > source Sun XACML implementation. > > > > Because of the dependence on Sun XACML (which is XACML 2.0) the > interface was missing some XACML 3.0 features. More recently this was > corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was > done by the JPMC team to support calling a remote PDP. WSo2 is also > pursuing this capability. > > > > A second, higher level interface, PEPAPI was also defined. PEPAPI is > more intended for application developers with little knowledge of > XACML. It allows Java objects which contain attribute information to be > passed in. Conversion methods, called mappers extract information from > the objects and present it in the format expected by XACML. Some > implementers have chosen to implement PEPAPI directly against their > PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface > which closely matches the Java one. > > > > Examples of more speculative work include: proposals for registration > and dispatch of Obligation and Advice handlers, a scheme called AMF to > tell PIPs how to retrieve attributes and PIP code to implement it, > discussion of PoC code to demonstrate the use of XACML policies to > drive OAuth interations and a proposal to use XACML policies to express > OAuth scope. > > > > AT&T has recently contributed their extensive XACML framework to the > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > collection of Java interfaces and standard implementations of those > interfaces. The AT&T PDP engine is built on top of this framework and > represents a complete implementation of a XACML 3.0 PDP, including all > of the multi-decision profiles. In addition, the framework also > contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and > XACML JSON Profile v1.0 WD 14. The PEP API includes annotation > functionality, allowing application developers to simply annotate a > Java class to provide attributes for a request. The annotation support > removes the need for application developers to learn much of the API. > > > > The AT&T framework also includes interfaces and implementations to > standardize development of PIP engines that are used by the AT&T PDP > implementation, and can be used by other implementations built on top > of the AT&T framework. The framework also includes interfaces and > implementations for a PAP distributed cloud infrastructure of PDP nodes > that includes support for policy distribution and pip configurations. > This PAP infrastructure includes a web application administrative > console that contains a XACML 3.0 policy editor, attribute dictio
RE: [PROPOSAL] OpenAZ as new Incubator project
No, I am sorry this process is all new to me. I also created a page in the wiki with same content. (OpenAZProposal) Do I need to do something or can you cancel it? Hal > -Original Message- > From: John D. Ament [mailto:john.d.am...@gmail.com] > Sent: Thursday, November 13, 2014 5:03 PM > To: general@incubator.apache.org > Subject: Re: [PROPOSAL] OpenAZ as new Incubator project > > Hal, > > Per customs, would you mind if we cancel this and start with a > [DISCUSS] thread about OpenAZ? It's unclear if you meant this to be a > vote or something. > > John > > On Thu, Nov 13, 2014 at 4:14 PM, Hal Lockhart > wrote: > > > Abstract > > > > OpenAz is a project to create tools and libraries to enable the > > development of Attribute-based Access Control (ABAC) Systems in a > > variety of languages. In general the work is at least consistent with > > or actually conformant to the OASIS XACML Standard. > > > > Proposal > > > > Generally the work falls into two categories: ready to use tools > which > > implement standardized or well understood components of an ABAC > system > > and design proposals and proof of concept code relating to less well > > understood or experimental aspects of the problem. > > > > Much of the work to date has revolved around defining interfaces > > enabling a PEP to request an access control decision from a PDP. The > > XACML standard defines an abstract request format in xml and protocol > > wire formats in xaml and json, but it does not specify programmatic > interfaces in any language. > > The standard says that the use of XML (or JSON) is not required only > > the semantics equivalent. > > > > The first Interface, AzAPI is modeled closely on the XACML defined > > interface, expressed in Java. One of the goals was to support calls > to > > both a PDP local to the same process and a PDP in a remote server. > > AzAPI includes the interface, reference code to handle things like > the > > many supported datatypes in XACML and glue code to mate it to the > open > > source Sun XACML implementation. > > > > Because of the dependence on Sun XACML (which is XACML 2.0) the > > interface was missing some XACML 3.0 features. More recently this was > > corrected and > > WSo2 has mated it to their XACML 3.0 PDP. Some work was done by the > > JPMC team to support calling a remote PDP. WSo2 is also pursuing this > capability. > > > > A second, higher level interface, PEPAPI was also defined. PEPAPI is > > more intended for application developers with little knowledge of > > XACML. It allows Java objects which contain attribute information to > be passed in. > > Conversion methods, called mappers extract information from the > > objects and present it in the format expected by XACML. Some > > implementers have chosen to implement PEPAPI directly against their > PDP, omitting the use of AzAPI. > > Naomaru Itoi defined a C++ interface which closely matches the Java > one. > > > > Examples of more speculative work include: proposals for registration > > and dispatch of Obligation and Advice handlers, a scheme called AMF > to > > tell PIPs how to retrieve attributes and PIP code to implement it, > > discussion of PoC code to demonstrate the use of XACML policies to > > drive OAuth interations and a proposal to use XACML policies to > express OAuth scope. > > > > AT&T has recently contributed their extensive XACML framework to the > > project. > > > > The AT&T framework represents the entire XACML 3.0 object set as a > > collection of Java interfaces and standard implementations of those > > interfaces. The AT&T PDP engine is built on top of this framework > and > > represents a complete implementation of a XACML 3.0 PDP, including > all > > of the multi-decision profiles. In addition, the framework also > > contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 > and > > XACML JSON Profile v1.0 WD 14. The PEP API includes annotation > > functionality, allowing application developers to simply annotate a > > Java class to provide attributes for a request. The annotation > support > > removes the need for application developers to learn much of the API. > > > > The AT&T framework also includes interfaces and implementations to > > standardize development of PIP engines that are used by the AT&T PDP > > implementation, and can be used by other implementations built on top > > of the AT&T framework. The framework also includes interfaces and > > implemen
[PROPOSAL] OpenAZ as new Incubator project
rk 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 Rich Levinson < rich.levinson at oracle dot com> Ajith Nair Chris Rath Duanhua Tu The following people made other significant technical contributions. David Laurence Hal Lockhart 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
Request to permissions to edit wiki
Please add my account, "HalLockhart" to the wiki contributors group. Thanks, Hal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Finding a Champion
Thanks to everyone for the encouraging comments. I will report back to OpenAz and begin drafting a proposal. I suspect we will want Paul to act as our Champion, since WSO2 is already active in the project. I think the group will be glad to have Emmanuel and Colm help us as Mentors. Hal > -Original Message- > From: Colm O hEigeartaigh [mailto:cohei...@apache.org] > Sent: Wednesday, March 19, 2014 5:03 AM > To: general@incubator.apache.org > Subject: Re: Finding a Champion > > I'm also willing to help out (as a mentor). Apache CXF has a PEP that > uses a interface to convert a service request to a XACML request, and > ships with an implementation that uses OpenSAML to create the request. > I was planning to dedicate some time to switching to use OpenAZ > instead. > > Colm. > > > On Wed, Mar 19, 2014 at 3:00 AM, Paul Fremantle > wrote: > > > I'm also willing to champion this. > > > > Paul > > > > > > On Tue, Mar 18, 2014 at 9:57 PM, Emmanuel Lécharny > > > >wrote: > > > > > Le 3/18/14 7:47 PM, Rich Bowen a écrit : > > > > > > > > On 03/18/2014 02:40 PM, Hal Lockhart wrote: > > > >> I am a newbie here. I am involved in an open source project > > > >> called OpenAz. It is focus is to provide tools and components > for > > > >> developing authorization and access control systems. Our web > page > > > >> (and wiki) is > > > >> here: > > > >> > > > >> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page > > > >> > > > >> We are using SourceForge for the code. We use the Apache license > > > >> throughout. The project was started in 2009 and was very small > > > >> initially. More recently we have been gaining more momentum and > > > >> participants. We intend to propose to become an Incubator > project. > > > >> > > > >> I have looked at the documents and lists and I believe I > > > >> understand how to write the first draft of a Proposal. However, > > > >> how does one go about recruiting a Champion. Does it make sense > > > >> to draft a proposal and then try to attract a Champion to it or > > > >> is there a better way to proceed? > > > >> > > > >> > > > > This email was a good start. > > > > > > > > Also, finding an existing Apache member who's either active in > > > > your community, or is a user of your stuff, would be a good thing > > > > to investigate. I see from your website that WSO2 is somehow > involved. > > > > There's several ASF members there. > > > > > > > > Failing that, tell us why your project is awesome and why we'd > > > > want to be involved. > > > > > > > If you don't find a more suitable champion, I'd be please to offer > > > my support. > > > > > > There is defintively a need for some XACML related project at the > ASF. > > > > > > -- > > > Regards, > > > Cordialement, > > > Emmanuel Lécharny > > > www.iktek.com > > > > > > > > > --- > - > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > -- > > Paul Fremantle > > Co-Founder and CTO, WSO2 > > Member of the Apache Software Foundation OASIS WS-RX TC Co-chair > > > > blog: http://pzf.fremantle.org > > twitter: @pzfreo > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Finding a Champion
I am a newbie here. I am involved in an open source project called OpenAz. It is focus is to provide tools and components for developing authorization and access control systems. Our web page (and wiki) is here: http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page We are using SourceForge for the code. We use the Apache license throughout. The project was started in 2009 and was very small initially. More recently we have been gaining more momentum and participants. We intend to propose to become an Incubator project. I have looked at the documents and lists and I believe I understand how to write the first draft of a Proposal. However, how does one go about recruiting a Champion. Does it make sense to draft a proposal and then try to attract a Champion to it or is there a better way to proceed? Hal Lockhart - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
