incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator
Date Tue, 13 Jan 2015 09:58:23 GMT
+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

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