incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RATH, CHRISTOPHER A (CHRISTOPHER A)" <...@research.att.com>
Subject RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
Date Tue, 06 Jan 2015 17:44:52 GMT
+1.

--
Christopher A. Rath
Director Inventive Science – Intelligent Systems Research Department

-----Original Message-----
From: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Sent: Monday, January 05, 2015 10:28 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

+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


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