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