incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
Date Tue, 06 Jan 2015 17:09:34 GMT
+1.

Colm.

On Tue, Jan 6, 2015 at 3:27 AM, Hadrian Zbarcea <hzbarcea@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: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
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message