+1 > On Jan 13, 2015, at 4:58 AM, Paul Fremantle <pzf...@gmail.com> wrote: > > +1 from me! > > Paul > > On Thu, Jan 8, 2015 at 6:10 PM, Dilli Arumugam <darumu...@hortonworks.com> > wrote: > >> +1 >> >> On Thu, Jan 8, 2015 at 7:14 PM, DRAGOSH, PAMELA L (PAM) < >> pdrag...@research.att.com> wrote: >> >>> +1 >>> >>> >>> Pam >>> >>> Pamela L. Dragosh >>> PMTS Research >>> One AT&T Way >>> 4D-170P >>> Bedminster, NJ 07921 >>> 908-901-2120 - Office >>> pdrag...@research.att.com >>> >>> >>> >>> On 1/5/15, 2:04 PM, "Hal Lockhart" <hal.lockh...@oracle.com> wrote: >>> >>>> I added a comma and the word "and" to the Mentors section. The Mentors >>>> are: >>>> >>>> Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea >>>> >>>> Do you see any other formatting errors? >>>> >>>> Hal >>>> >>>>> -----Original Message----- >>>>> From: Roman Shaposhnik [mailto: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 >>> >>> >> >> -- >> CONFIDENTIALITY NOTICE >> NOTICE: This message is intended for the use of the individual or entity to >> which it is addressed and may contain information that is confidential, >> privileged and exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby notified that >> any printing, copying, dissemination, distribution, disclosure or >> forwarding of this communication is strictly prohibited. If you have >> received this communication in error, please contact the sender immediately >> and delete it from your system. Thank You. >> > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Member of the Apache Software Foundation > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > twitter: @pzfreo
--------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
