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