incubator-general mailing list archives

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


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


Mime
View raw message