Skip to main content

[identity-api-spec commits] [identity-api-spec~git-docbook:ab754259] edits by prateek

  • From: monzillo@...
  • To: commits@...
  • Subject: [identity-api-spec commits] [identity-api-spec~git-docbook:ab754259] edits by prateek
  • Date: Tue, 17 Sep 2013 00:41:06 +0000

Project:    identity-api-spec
Repository: git-docbook
Revision:   ab75425952f8a807591bc2a89e4d3986410b5622
Author:     monzillo
Date:       2013-09-17 00:38:15 UTC
Link:       

Log Message:
------------
edits by prateek


Revisions:
----------
ab75425952f8a807591bc2a89e4d3986410b5622


Modified Paths:
---------------
EarlyDraft/dist/html/identity-api-spec-early-draft-01.html
EarlyDraft/src/Overview/overview.xml
EarlyDraft/src/Preface/preface.xml
EarlyDraft/src/References/references.xml


Diffs:
------
--- a/EarlyDraft/dist/html/identity-api-spec-early-draft-01.html
+++ b/EarlyDraft/dist/html/identity-api-spec-early-draft-01.html
@@ -1,4 +1,4 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; 
charset=ISO-8859-1"><title>JSR-351: The Java Identity API</title><meta 
name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body 
bgcolor="white" text="black" link="#0000FF" vlink="#840084" 
alink="#0000FF"><div class="book"><div class="titlepage"><div><div><h1 
class="title"><a name="idp4672"></a>JSR-351: The Java Identity 
API</h1></div><div><div class="authorgroup"><div class="othercredit"><h3 
class="othercredit"><span class="othername">JSR-351 Expert 
Group</span></h3></div><div class="author"><h3 class="author"><span 
class="firstname">Ron</span> <span class="surname">Monzillo</span></h3><div 
class="affiliation"><span class="orgname">Oracle America, 
Inc.<br></span></div></div><div class="author"><h3 class="author"><span 
class="firstname">Prateek</span> <span class="surname">Mishra</span></h3><div 
class="affiliation"><span class="orgname">Oracle America, 
Inc.<br></span></div></div></div></div><div><p class="
 releaseinfo">Early Draft</p></div></div><hr></div><div 
class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span 
class="preface"><a href="#license">Specification 
License</a></span></dt><dt><span class="preface"><a 
href="#preface">Preface</a></span></dt><dt><span class="chapter"><a 
href="#overview">1. Overview</a></span></dt><dd><dl><dt><span 
class="section"><a href="#overview.info.model">Information 
model</a></span></dt><dt><span class="section"><a 
href="#overview.services.model">services model</a></span></dt><dt><span 
class="section"><a href="#overview.security.model">security 
model</a></span></dt><dt><span class="section"><a 
href="#overview.programming.model">programming 
model</a></span></dt></dl></dd><dt><span class="chapter"><a href="#api">2. 
Api</a></span></dt><dt><span class="appendix"><a href="#issues">A. 
Issues</a></span></dt><dt><span class="appendix"><a href="#glossary">B. 
Glossary</a></span></dt><dt><span class="appendix"><a href="#references">C. 
References</a>
 </span></dt><dt><span class="appendix"><a href="#history">D. Revision 
History</a></span></dt></dl></div><div class="preface"><div 
class="titlepage"><div><div><h1 class="title"><a 
name="license"></a>Specification 
License</h1></div></div></div><p>Specification: JSR-351 The Java Identity API 
("Specification")</p><p>Version: 1.0</p><p>Status: Early Draft 
Review</p><p>Anticipated Release Date: June 2014</p><p>Copyright � 2013 
Oracle America, Inc.</p><p>500 Oracle Parkway</p><p>Redwood City, California 
94065, U.S.A.</p><p>All rights reserved.</p><p>NOTICE</p><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; 
charset=ISO-8859-1"><title>JSR-351: The Java Identity API</title><meta 
name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body 
bgcolor="white" text="black" link="#0000FF" vlink="#840084" 
alink="#0000FF"><div class="book"><div class="titlepage"><div><div><h1 
class="title"><a name="idp464"></a>JSR-351: The Java Identity 
API</h1></div><div><div class="authorgroup"><div class="othercredit"><h3 
class="othercredit"><span class="othername">JSR-351 Expert 
Group</span></h3></div><div class="author"><h3 class="author"><span 
class="firstname">Ron</span> <span class="surname">Monzillo</span></h3><div 
class="affiliation"><span class="orgname">Oracle America, 
Inc.<br></span></div></div><div class="author"><h3 class="author"><span 
class="firstname">Prateek</span> <span class="surname">Mishra</span></h3><div 
class="affiliation"><span class="orgname">Oracle America, 
Inc.<br></span></div></div></div></div><div><p class="r
 eleaseinfo">Early Draft</p></div></div><hr></div><div 
class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span 
class="preface"><a href="#license">Specification 
License</a></span></dt><dt><span class="preface"><a 
href="#preface">Preface</a></span></dt><dt><span class="chapter"><a 
href="#overview">1. Overview</a></span></dt><dd><dl><dt><span 
class="section"><a href="#overview.info.model">Information 
model</a></span></dt><dt><span class="section"><a 
href="#overview.services.model">Services model</a></span></dt><dt><span 
class="section"><a href="#overview.security.model">Security 
model</a></span></dt><dt><span class="section"><a 
href="#overview.programming.model">Programming 
model</a></span></dt></dl></dd><dt><span class="chapter"><a href="#api">2. 
Api</a></span></dt><dt><span class="appendix"><a href="#issues">A. 
Issues</a></span></dt><dt><span class="appendix"><a href="#glossary">B. 
Glossary</a></span></dt><dt><span class="appendix"><a href="#references">C. 
References</a><
 /span></dt><dt><span class="appendix"><a href="#history">D. Revision 
History</a></span></dt></dl></div><div class="preface"><div 
class="titlepage"><div><div><h1 class="title"><a 
name="license"></a>Specification 
License</h1></div></div></div><p>Specification: JSR-351 The Java Identity API 
("Specification")</p><p>Version: 1.0</p><p>Status: Early Draft 
Review</p><p>Anticipated Release Date: June 2014</p><p>Copyright � 2013 
Oracle America, Inc.</p><p>500 Oracle Parkway</p><p>Redwood City, California 
94065, U.S.A.</p><p>All rights reserved.</p><p>NOTICE</p><p>
 The Specification is protected by copyright and the information
 described therein may be protected by one or more U.S. patents, foreign
 patents, or pending applications. Except as provided under the
@@ -111,226 +111,242 @@ and prevails over any conflicting or additional terms 
of any quote,
 order, acknowledgment, or other communication between the parties
 relating to its subject matter during the term of this Agreement. No
 modification to this Agreement will be binding, unless in writing and
-signed by an authorized representative of each party.</p></div><div 
class="preface"><div class="titlepage"><div><div><h1 class="title"><a 
name="preface"></a>Preface</h1></div></div></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface1"></a>Status</h2></div></div></div><p>This document is the 
Early Draft of the Java Identity API specification.
-        It represents the work of the expert group, and is provided to 
engage the
-        public in the process of review and completion of the specification.
-        </p></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface2"></a>Audience</h2></div></div></div><p>The document is 
intended for architects and developers with
-        an interest in defining the Java Identity API, or in developing
-        applications that would make use of the API. It also intended for
-        developers of the RI, and TCK, and for evaluation by those who are
-        interested in providing an implementation of one or more of the 
software
-        components defined by the finished specification.
-        </p></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface3"></a>Abstract</h2></div></div></div><p>The objective of this 
project is to define application programming
-        interfaces and identity interaction models to facilitate the
-        use and creation of identity by Java applications. To meet this 
objective,
-        this specification defines a representation for identity in Java, an
-        attribute service as a point of governance and
-        interaction with identity, and an identity repository integration
-        architecture in support of distributed sources of identity.
-        </p><p>The identity representation is integrated with the Java 
security model
-        and captures identity attributes as named, metadata qualified (e.g., 
issuer,
-        validity period, usage constraints) representations of identity 
values.
-        The attribute service is a protected service from which applications 
request
-        interfaces to operate on the content of the integrated identity 
repositories.
-        In addition to value based interactions with identity, and in 
support of
-        privacy preserving exchange of identity, the attribute also
-        service provides interfaces to obtain and operate on references to
-        identity attributes. Above the interfaces provided by the attribute
-        service, the specification also defines annotations and inteceptor
-        bindings that provide application developers with a simple means to
-        cause identity attributes to be obtained or provided to the attribute
-        service by an annotated application.
-        </p></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface5.5"></a>Motivating Use Cases</h2></div></div></div><p>The 
specification is being developed to provide an API to support
-        the following use cases. As the Expert Group and community identify
-        additional motivating use cases, we would expect the API to evolve
-        to accomodate them.
-        </p><div class="itemizedlist"><ul class="itemizedlist" 
style="list-style-type: disc; "><li class="listitem"><p>Application is Client 
of Attribute Service</p><p>At runtime, an application interacts with an 
Attribute Service
-                to perform operations on individual attributes or 
collections of
-                attributes pertaining to one or more identified entities. The
-                application may be a single user application, e.g., running 
on a
-                consumer device, or it may be deployed on a server, e.g., a 
web application,
-                where it responds to requests from muliple users. In one 
scenario, the
-                operations are performed on the attributes of the entity
-                identified by the access control context of the thread on 
which
-                the interaction with the Attribute Service is performed. In
-                another scenario the operations are performed on the 
attributes
-                of one or more entities independent of the entity associated
-                with the thread. At compile time, target attributes may be
-                identified using logical constructs that are bound, at 
runtime,
-                by the Attribute Service to physical attribute repositories 
and
-                values. In some scenarios, only lookup or read type attribute
-                operations will be performed. In other scenarios, update,
-                create, and or delete operations will also be performed.
-                In user registration scenarios, an application will create
-                entities that are integrated with an authentication system
-                such that the authentication system can establish an access
-                control context that identifies the entity. Some such
-                applications will establish the governance policy for the
-                attributes of the entities they create.</p></li><li 
class="listitem"><p>Application is Attribute Provider</p><p>An application 
embodies attributes that are to be made available
-                to other applications via the attribute service. These 
attributes are
-                associated with specific scopes or contexts, such that 
client applications
-                may be provided with attributes appropriate to the context 
in which the
-                client is operating. In some scenarios, the attributes are 
provided from
-                a common context independent of that of the client 
application. In other
-                scenarios, the attributes are provided from a context 
associated with
-                the client application, or from a request, session, or user 
authentication
-                context shared between the attribute provider and the client
-                application or system.</p><p>In one specific use case, an 
application is a client of an
-                authorization system and the policy being enforced by the 
authorization
-                system is based on contextual attribute values held within 
the application,
-                The application cannot reliably predict the additional 
contextual
-                application attributes that will be required by the 
authorization system.
-                As such, the application (as attribute provider) must 
respond to
-                requests, from the decision agent, for additional contextual
-                attributes as needed by the authorization system.
-                </p></li><li class="listitem"><p>Identity 
Propagation</p><p>Application or system wishes to propagate Identity 
attributes to another
-                system or application. In one common case, the attributes to 
be propagated
-                will be those of the current authenticated entity. In other 
cases, the attributes
-                o be propagated may pertain to an arbitrary entity. In some 
cases, specific
-                attributes are to be propagated; while in others, it will be 
necessary to propagate
-                an ability for the recipient to acquire additional 
attributes (of some entity)
-                that the propagator may either be unfamiliar with or 
unauthorized to acquire.
-                It will also be necessary to be able to pass attributes by 
reference, in order
-                to force the recipient to interact with the attribute 
service to acquire
-                the attribute values (which will ensure that it have rights 
to do so).
-                In cases where the receiving system is outside the java 
identity framework
-                (including cases where it is a non-Java system), it will be 
necessary for
-                the propagator to represent the attributes in a form that 
will be understood
-                by the recipient.</p></li><li 
class="listitem"><p>Authentication System binds Attributes to Java 
Authentication State</p><p>A Java authentication system collects and 
validates security mechanism-specific
-                tokens or credentials and establishes a corresponding 
representation of authentication
-                state within the Java access control context of the thread 
for which the authentication
-                was performed.</p><p>The credentials may be collected 
directly from the user of the runtime environment,
-                or from messages conveyed to the runtime. The authentication 
system converts the
-                validated credentials into authenticated identity attributes 
which are then
-                established within the Java access control context. The 
access control context
-                is established within the runtime environment for which the 
system is performing
-                the authentication. The authentication system may use the 
authenticated identity
-                attributes to acquire additional identity attributes 
pertaining to the authenticated
-                entity. When additional attributes are acquired, they are 
acquired from an Attribute
-                Service, and are represented in the established access 
control context. The Attribute
-                Service must be able to locate any additional attributes 
requested by the
-                authentication system based on the authenticated identity 
attributes.
-                The Attribute Service must return any additional attributes 
in a form that
-                can be established within the access control context and 
suitably conveyed within
-                Java the runtime.
-                </p></li><li class="listitem"><p>Authorization Subsystem 
Consumes Attributes</p><p>The Authorization Subsystem is presumed to be 
composed of one or more decision
-                agents each exporting a decision interface for use by policy 
enforcement points embedded
-                in the application or middleware. The decision agents make 
calls to an underlying Policy
-                engine. Each decision agent is responsible for converting 
the artifacts passed to it, via
-                its associated decision interface, to the artifacts required 
by the Policy engine. The
-                decision agents are presumed to be co-located with an 
Attribute Service and with the
-                enforcement points that rely on them.
-                </p><p>An application or runtime/IDE uses decision interface 
to embed enforcement point(s).
-                Target resource, action, and actor to be tested for 
authorization are established at the
-                enforcement point and passed to the decision agent via the 
decision interface. In one
-                scenario, the target resource and action are derived from 
the Java language coordinates
-                of the enforcement point (i.e., the method or class on which 
the enforcement point is embedded).
-                In another scenario, including instance specific access 
control, the target resource a
-                nd action are established using decision interface specific 
objects (e.g., XACML Resource
-                attributes, or Java Permission objects) that are orthogonal 
to the language coordinates.
-                In active entity scenarios, the enforcement point may test 
the actor who is currently
-                executing the code at the enforcement point (as represented 
by the access control context).
-                In target entity scenarios, the enforcement point may test 
some other proposed or predicted
-                actor (e.g., as represented in an unbound access control 
context). In either case, the actor
-                is commonly expected to correspond to some potential user of 
the system, but may also
-                include information identifying the code from which an 
invocation or potential invocation
-                originated.</p><p>The Policy engine may use the identity 
attributes of the actor to request additional
-                attributes from the attribute service. The Policy engine may 
interact with the application
-                to obtain any additional contextual attributes determined to 
be required to complete the
-                processing of the access control decision. For the case 
where the Policy engine is remote
-                with respect to the decision agent (and thus the enforcement 
point and the corresponding
-                Attribute Service) the Policy engine may direct its requests 
for additional attributes
-                to the decision agent; which would then interact with the 
Attribute service or application,
-                as appropriate. In all cases, it is the Policy engine that 
is responsible for determining,
-                based on the rules that it is processing, when an additional 
attribute should be acquired,
-                and whether to interact with the Attribute Service, the 
application, or the decision agent
-                to acquire it. </p></li></ul></div></div><div 
class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a name="preface6"></a>Java.Net 
Projects</h2></div></div></div><p></p><div class="itemizedlist"><ul 
class="itemizedlist" style="list-style-type: disc; "><li 
class="listitem"><p>The API is being developed under the java.net project at
-                    <a class="ulink" 
href="http://java.net/projects/identity-api-spec" ;
target="_top">http://java.net/projects/identity-api-spec</a>. The
-                javadoc for the ealy draft of the API is available from this
-                project's website
-                    <a class="ulink" 
href="http://identity-api-spec.java.net/" ;
target="_top">http://identity-api-spec.java.net/</a>
-                </p></li><li class="listitem"><p>The reference 
implementation is being developed under
-                the Nobis java.net project which can be found at:
-                    <a class="ulink" href="http://java.net/projects/nobis" ;
target="_top">http://java.net/projects/nobis</a>.
-                </p></li></ul></div></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface5"></a>Acknowledgements</h2></div></div></div><p>This document 
embodies the work of The JSR 351 Expert group
-        along with contributions made from the public via the Nobis Reference
-        Implementation. The contributors are listed below.
-        </p><div class="informaltable"><table width="100%" 
border="0"><colgroup><col width="2" align="left"><col width="2" 
align="left"></colgroup><tbody><tr><td align="left">Todd Aven</td><td 
align="left">Goldman Sachs</td></tr><tr><td align="left">Boleslaw 
Dawidowicz</td><td align="left">RedHat</td></tr><tr><td align="left">Vaibhav 
Gowadia</td><td align="left">Individual</td></tr><tr><td align="left">Will 
Hopkins</td><td align="left">Oracle</td></tr><tr><td align="left">Werner 
Keil</td><td align="left">individual</td></tr><tr><td align="left">Pete 
Muir</td><td align="left">Red Hat</td></tr><tr><td align="left">Nicholas 
Parks</td><td align="left">Individual</td></tr><tr><td align="left">Bruce 
Rich</td><td align="left">IBM</td></tr><tr><td align="left">Kenneth 
Riggio</td><td align="left">Live Nation</td></tr><tr><td align="left">Anil 
Saldhana</td><td align="left">Redhat</td></tr><tr><td align="left">Jeff 
Williams</td><td align="left">Aspect Security</td></tr><tr><td 
align="left">Ste
 phan Zlatarev</td><td align="left">SAP</td></tr><tr><td align="left">Prateek 
Mishra</td><td align="left">Oracle</td></tr><tr><td align="left">Ron 
Monzillo</td><td 
align="left">Oracle</td></tr></tbody></table></div></div><div 
class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a 
name="preface4"></a>Keywords</h2></div></div></div><p>In this document, the 
keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
-        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
"OPTIONAL"
-        are to be interpreted as described in RFC 2119.
-        </p></div></div><div class="chapter"><div 
class="titlepage"><div><div><h1 class="title"><a 
name="overview"></a>Chapter�1.�Overview</h1></div></div></div><div 
class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span 
class="section"><a href="#overview.info.model">Information 
model</a></span></dt><dt><span class="section"><a 
href="#overview.services.model">services model</a></span></dt><dt><span 
class="section"><a href="#overview.security.model">security 
model</a></span></dt><dt><span class="section"><a 
href="#overview.programming.model">programming 
model</a></span></dt></dl></div><p>
-        This chapter provides a high level descripton of the information, 
service, security,
-        and programming models of the Java Identity API.
-    </p><div class="section"><div class="titlepage"><div><div><h2 
class="title" style="clear: both"><a 
name="overview.info.model"></a>Information model</h2></div></div></div><p>The 
Identity Api adopts a simple model for network Identity, where
-            <span class="emphasis"><em>Entities</em></span>, (i.e. persons, 
computers, services, documents, ...) 
-            are represented as collections of named, metadata qualified, 
values called
-            <span class="emphasis"><em>Attributes/</em></span>, where the 
<span class="emphasis"><em>metadata</em></span>  
-            is used to convey named property values, (e.g., issuer, validity 
period, 
-            usage constraints, ...) within the attribute 
representation.</p><p>An important feature of this simple model is that the 
attribute collection that 
-            corresponds to an entity is a stable container for which a 
durable, 
-            attribute-independent <span class="emphasis"><em>Entity 
Reference</em></span> may be 
-            formed to identify the collection and without exposing the 
values of any attributes 
-            within the collection. Likewise, for the individual attributes 
within an entity, 
-            the model defines a value-independent <span 
class="emphasis"><em>Attribute Reference</em></span> 
-            form. Entity and attribute references allow for the privacy 
preserving exhange of
-            handles to the corresponding artifacts; by retaining the ability 
to authorize 
-            access by the handle recipient to the corresponding identity 
values.
-            The reference for an identity attribute is available from the 
Java representation of the
-            attribute. Entity references are obtained by performing a <span 
class="emphasis"><em>search</em></span>
-            operation on an <span class="emphasis"><em>Attribute 
Repository</em></span> or <span class="emphasis"><em>Attribute 
Provider</em></span>.
-            Attribute repositories and providers are described in <a 
class="xref" href="#overview.services.model" title="services model">the 
section called &#8220;services model&#8221;</a>.
-        </p><p>Entity and Attribute References are composed of two 
parts:</p><div class="itemizedlist"><ul class="itemizedlist" 
style="list-style-type: disc; "><li class="listitem"><p>
-                    a <span class="emphasis"><em>Provider Lookup 
Context</em></span> that describes the attribute 
-                    repository from which the reference was obtained, and 
thus at which it may used 
-                    to obtain the corresponding entity or attribute.
-                </p></li><li class="listitem"><p>
-                    the repository specific data by which the referenced 
entity or attribute 
-                    may be located by the repository.
-                </p></li></ul></div></div><div class="section"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="overview.services.model"></a>services 
model</h2></div></div></div><p>The Identity Api defines an <span 
class="emphasis"><em>Attribute Service</em></span> as the 
-            point of governance and interaction with identity. The Identity 
Api also defines
-            an attribute repository integration architecture which is 
applied within 
-            an attribute service implementation such that it serves as an 
integration 
-            point for distributed sources of identity. Sources of identiy 
are obtained from
-            <span class="emphasis"><em>Repository Agents</em></span> that 
are registered within the attribute
-            service. Each registeration is represented by a <span 
class="emphasis"><em>Repository Descriptor</em></span> 
-            that names the implementation class of the repository agent, and 
the name of the attribute
-            repository registered with the agent.</p><p>Client applications 
interact with the <span class="emphasis"><em>Provider Lookup 
Service</em></span>
-            of the attribute service to obtain an <span 
class="emphasis"><em>Attribute Provider</em></span>
-            corresponding to a provider lookup context. An attribute 
provider is a proxy that
-            encapsulates the interfaces of an attribute repository, 
including such that they 
-            are protected as described in <a class="xref" 
href="#overview.security.model" title="security model">the section called 
&#8220;security model&#8221;</a>. The attribute
-            repository maps the interfaces of the attribute repository 
interface to the
-            interfaces and protocols of the underlying identity 
repository.</p><p>An Attribute provider interface features methods to acquire 
the attribute 
-            <span class="emphasis"><em>lookup</em></span> and <span 
class="emphasis"><em>update</em></span> service implementations 
-            from the attribute provider. In support of its lookup service, 
the attribute provider
-            interface also supports a <span 
class="emphasis"><em>predicate</em></span>builder facility, which is
-            used to construct entity and attribute <span 
class="emphasis"><em>selectors</em></span> for use in search
-            operations at the lookup service. The update service of the 
attribute provider features
-            methods to create entities, and to operate on existing entities 
and their contained attributes
-            through their entity and attribute references.</p><p>As noted 
above, the provider lookup service, returns an attribute provider
-            corresponding to an argument provider lookup context. In 
addition to 
-            <span class="emphasis"><em>leaf</em></span> contexts constructed 
from a repository descriptor,
-            the provider lookup service also interprets provider lookup 
contexts
-            that describe the derivation of attribute providers from argument
-            attribute providers by selection, aggregation and natural join. 
It is the
-            provider lookup service of the attribute service that provides 
the 
-            implementation of the returned attribute provider.</p></div><div 
class="section"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a name="overview.security.model"></a>security 
model</h2></div></div></div><p>The security model of the Java Identity Api is 
composed of the services
-            protection model, and the content protection model. The services 
protection
-            model employs the Java Security Manager to determine if the 
calling 
-            Java access conttol context has been granted the 
-            <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/permission/AttributeRepositryPermission.html";
 target="_top">AttributeRepositoryPermission</a>
-            required to invoke the requested service at the corresponding 
attribute
-            provider. The Content protection model is implemented by the 
-        </p><p>
-            Describe content protection model
-            including credentials and how they are obtained.
-        </p></div><div class="section"><div class="titlepage"><div><div><h2 
class="title" style="clear: both"><a 
name="overview.programming.model"></a>programming 
model</h2></div></div></div><p>The Identity Api provides 
-            use of programmatic api 
-            injection by annotation
-            integration with CDI
-            entity consumers and providers
-            integration with subjects and principals of the Java Security 
Model, 
-        </p></div></div><div class="chapter"><div 
class="titlepage"><div><div><h1 class="title"><a 
name="api"></a>Chapter�2.�Api</h1></div></div></div><p>The javadoc 
corresponding to the Early Draft of the specification is
+signed by an authorized representative of each party.</p></div><div 
class="preface"><div class="titlepage"><div><div><h1 class="title"><a 
name="preface"></a>Preface</h1></div></div></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface1"></a>Status</h2></div></div></div><p>This document is the 
Early Draft of the Java Identity API 
+               specification. It represents the work of the expert group, 
and is 
+               provided to engage the public in the process of review and 
completion 
+               of the specification.</p></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface2"></a>Audience</h2></div></div></div><p>The document is 
intended for architects and developers with an 
+               interest in defining the Java Identity API, or in developing 
+               applications that would make use of the API. It also intended 
for 
+               developers of the RI, and TCK, and for evaluation by those 
who are 
+               interested in providing an implementation of one or more of 
the 
+               software components defined by the finished 
specification.</p></div><div class="simplesect"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="preface3"></a>Abstract</h2></div></div></div><p>The objective of this 
project is to define application 
+               programming interfaces and identity interaction models to 
facilitate 
+               the use and creation of identity by Java applications. To 
meet this 
+               objective, this specification defines a <span 
class="emphasis"><em>representation for 
+               identity</em></span> in Java, an <span 
class="emphasis"><em>attribute</em></span> 
+               service as a point of governance and interaction with 
identity, and 
+               an <span class="emphasis"><em>identity repository 
integration</em></span> architecture 
+               in support of distributed sources of identity.</p><p>The 
identity representation is integrated with the Java 
+               security model and captures identity attributes as named, 
metadata 
+               qualified (e.g., issuer, validity period, usage constraints) 
+               representations of identity values. The attribute service is 

+               protected service from which applications request interfaces 
to 
+               operate on the content of the integrated identity 
repositories. In 
+               addition to value based interactions with identity, and in 
support of 
+               privacy preserving exchange of identity, the attribute also 
service 
+               provides interfaces to obtain and operate on references to 
identity 
+               attributes. Above the interfaces provided by the attribute 
service, 
+               the specification also defines annotations and inteceptor 
bindings 
+               that provide application developers with a simple means to 
cause 
+               identity attributes to be obtained or provided to the 
attribute 
+               service by an annotated application.</p></div><div 
class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a name="preface5.5"></a>Motivating Use 
Cases</h2></div></div></div><p>The specification is being developed to 
provide an API to 
+               support the following use cases. As the Expert Group and 
community 
+               identify additional motivating use cases, we would expect the 
API to 
+               evolve to accomodate them.</p><div class="itemizedlist"><ul 
class="itemizedlist" style="list-style-type: disc; "><li 
class="listitem"><p>Application is Client of Attribute Service</p><p>At 
runtime, an application interacts with an Attribute 
+                               Service to perform operations on individual 
attributes or 
+                               collections of attributes pertaining to one 
or more identified 
+                               entities. The application may be a single 
user application, e.g., 
+                               running on a consumer device, or it may be 
deployed on a server, 
+                               e.g., a web application, where it responds to 
requests from muliple 
+                               users. In one scenario, the operations are 
performed on the 
+                               attributes of the entity identified by the 
access control context 
+                               of the thread on which the interaction with 
the Attribute Service 
+                               is performed. In another scenario the 
operations are performed on 
+                               the attributes of one or more entities 
independent of the entity 
+                               associated with the thread. At compile time, 
target attributes may 
+                               be identified using logical constructs that 
are bound, at runtime, 
+                               by the Attribute Service to physical 
attribute repositories and 
+                               values. In some scenarios, only lookup or 
read type attribute 
+                               operations will be performed. In other 
scenarios, update, create, 
+                               and or delete operations will also be 
performed. In user 
+                               registration scenarios, an application will 
create entities that 
+                               are integrated with an authentication system 
such that the 
+                               authentication system can establish an access 
control context that 
+                               identifies the entity. Some such applications 
will establish the 
+                               governance policy for the attributes of the 
entities they 
+                               create.</p></li><li 
class="listitem"><p>Application is Attribute Provider</p><p>An application 
embodies attributes that are to be made 
+                               available to other applications via the 
attribute service. These 
+                               attributes are associated with specific 
scopes or contexts, such 
+                               that client applications may be provided with 
attributes 
+                               appropriate to the context in which the 
client is operating. In 
+                               some scenarios, the attributes are provided 
from a common context 
+                               independent of that of the client 
application. In other scenarios, 
+                               the attributes are provided from a context 
associated with the 
+                               client application, or from a request, 
session, or user 
+                               authentication context shared between the 
attribute provider and 
+                               the client application or system.</p><p>In 
one specific use case, an application is a client of an 
+                               authorization system and the policy being 
enforced by the 
+                               authorization system is based on contextual 
attribute values held 
+                               within the application, The application 
cannot reliably predict the 
+                               additional contextual application attributes 
that will be required 
+                               by the authorization system. As such, the 
application (as attribute 
+                               provider) must respond to requests, from the 
decision agent, for 
+                               additional contextual attributes as needed by 
the authorization 
+                               system.</p></li><li 
class="listitem"><p>Identity Propagation</p><p>Application or system wishes 
to propagate Identity attributes 
+                               to another system or application. In one 
common case, the 
+                               attributes to be propagated will be those of 
the current 
+                               authenticated entity. In other cases, the 
attributes o be 
+                               propagated may pertain to an arbitrary 
entity. In some cases, 
+                               specific attributes are to be propagated; 
while in others, it will 
+                               be necessary to propagate an ability for the 
recipient to acquire 
+                               additional attributes (of some entity) that 
the propagator may 
+                               either be unfamiliar with or unauthorized to 
acquire. It will also 
+                               be necessary to be able to pass attributes by 
reference, in order 
+                               to force the recipient to interact with the 
attribute service to 
+                               acquire the attribute values (which will 
ensure that it have rights 
+                               to do so). In cases where the receiving 
system is outside the java 
+                               identity framework (including cases where it 
is a non-Java system), 
+                               it will be necessary for the propagator to 
represent the attributes 
+                               in a form that will be understood by the 
recipient.</p></li><li class="listitem"><p>Authentication System binds 
Attributes to Java Authentication 
+                               State</p><p>A Java authentication system 
collects and validates security 
+                               mechanism-specific tokens or credentials and 
establishes a 
+                               corresponding representation of 
authentication state within the 
+                               Java access control context of the thread for 
which the 
+                               authentication was performed.</p><p>The 
credentials may be collected directly from the user of 
+                               the runtime environment, or from messages 
conveyed to the runtime. 
+                               The authentication system converts the 
validated credentials into 
+                               authenticated identity attributes which are 
then established within 
+                               the Java access control context. The access 
control context is 
+                               established within the runtime environment 
for which the system is 
+                               performing the authentication. The 
authentication system may use 
+                               the authenticated identity attributes to 
acquire additional 
+                               identity attributes pertaining to the 
authenticated entity. When 
+                               additional attributes are acquired, they are 
acquired from an 
+                               Attribute Service, and are represented in the 
established access 
+                               control context. The Attribute Service must 
be able to locate any 
+                               additional attributes requested by the 
authentication system based 
+                               on the authenticated identity attributes. The 
Attribute Service 
+                               must return any additional attributes in a 
form that can be 
+                               established within the access control context 
and suitably conveyed 
+                               within Java the runtime.</p></li><li 
class="listitem"><p>Authorization Subsystem Consumes Attributes</p><p>The 
Authorization Subsystem is presumed to be composed of one 
+                               or more decision agents each exporting a 
decision interface for use 
+                               by policy enforcement points embedded in the 
application or 
+                               middleware. The decision agents make calls to 
an underlying Policy 
+                               engine. Each decision agent is responsible 
for converting the 
+                               artifacts passed to it, via its associated 
decision interface, to 
+                               the artifacts required by the Policy engine. 
The decision agents 
+                               are presumed to be co-located with an 
Attribute Service and with 
+                               the enforcement points that rely on 
them.</p><p>An application or runtime/IDE uses decision interface to 
+                               embed enforcement point(s). Target resource, 
action, and actor to 
+                               be tested for authorization are established 
at the enforcement 
+                               point and passed to the decision agent via 
the decision interface. 
+                               In one scenario, the target resource and 
action are derived from 
+                               the Java language coordinates of the 
enforcement point (i.e., the 
+                               method or class on which the enforcement 
point is embedded). In 
+                               another scenario, including instance specific 
access control, the 
+                               target resource a nd action are established 
using decision 
+                               interface specific objects (e.g., XACML 
Resource attributes, or 
+                               Java Permission objects) that are orthogonal 
to the language 
+                               coordinates. In active entity scenarios, the 
enforcement point may 
+                               test the actor who is currently executing the 
code at the 
+                               enforcement point (as represented by the 
access control context). 
+                               In target entity scenarios, the enforcement 
point may test some 
+                               other proposed or predicted actor (e.g., as 
represented in an 
+                               unbound access control context). In either 
case, the actor is 
+                               commonly expected to correspond to some 
potential user of the 
+                               system, but may also include information 
identifying the code from 
+                               which an invocation or potential invocation 
originated.</p><p>The Policy engine may use the identity attributes of the 
+                               actor to request additional attributes from 
the attribute service. 
+                               The Policy engine may interact with the 
application to obtain any 
+                               additional contextual attributes determined 
to be required to 
+                               complete the processing of the access control 
decision. For the 
+                               case where the Policy engine is remote with 
respect to the decision 
+                               agent (and thus the enforcement point and the 
corresponding 
+                               Attribute Service) the Policy engine may 
direct its requests for 
+                               additional attributes to the decision agent; 
which would then 
+                               interact with the Attribute service or 
application, as appropriate. 
+                               In all cases, it is the Policy engine that is 
responsible for 
+                               determining, based on the rules that it is 
processing, when an 
+                               additional attribute should be acquired, and 
whether to interact 
+                               with the Attribute Service, the application, 
or the decision agent 
+                               to acquire it.</p></li></ul></div></div><div 
class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a name="preface6"></a>Java.Net 
Projects</h2></div></div></div><p></p><div class="itemizedlist"><ul 
class="itemizedlist" style="list-style-type: disc; "><li 
class="listitem"><p>The API is being developed under the java.net project at 
+                               <a class="ulink" 
href="http://java.net/projects/identity-api-spec" ;
target="_top">http://java.net/projects/identity-api-spec</a>. The 
+                               javadoc for the ealy draft of the API is 
available from this 
+                               project's website 
+                               <a class="ulink" 
href="http://identity-api-spec.java.net/" ;
target="_top">http://identity-api-spec.java.net/</a></p></li><li 
class="listitem"><p>The reference implementation is being developed under the 
+                               Nobis java.net project which can be found at: 
+                               <a class="ulink" 
href="http://java.net/projects/nobis" ;
target="_top">http://java.net/projects/nobis</a>.</p></li></ul></div></div><div
 class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a 
name="preface5"></a>Acknowledgements</h2></div></div></div><p>This document 
embodies the work of The JSR 351 Expert group 
+               along with contributions made from the public via the Nobis 
Reference 
+               Implementation. The contributors are listed below.</p><div 
class="informaltable"><table width="100%" border="0"><colgroup><col width="2" 
align="left"><col width="2" align="left"></colgroup><tbody><tr><td 
align="left">Todd Aven</td><td align="left">Goldman Sachs</td></tr><tr><td 
align="left">Boleslaw Dawidowicz</td><td align="left">RedHat</td></tr><tr><td 
align="left">Vaibhav Gowadia</td><td align="left">Individual</td></tr><tr><td 
align="left">Will Hopkins</td><td align="left">Oracle</td></tr><tr><td 
align="left">Werner Keil</td><td align="left">individual</td></tr><tr><td 
align="left">Pete Muir</td><td align="left">Red Hat</td></tr><tr><td 
align="left">Nicholas Parks</td><td align="left">Individual</td></tr><tr><td 
align="left">Bruce Rich</td><td align="left">IBM</td></tr><tr><td 
align="left">Kenneth Riggio</td><td align="left">Live Nation</td></tr><tr><td 
align="left">Anil Saldhana</td><td align="left">Redhat</td></tr><tr><td 
align="left">Jeff Williams</td><td align="left">Aspec
 t Security</td></tr><tr><td align="left">Stephan Zlatarev</td><td 
align="left">SAP</td></tr><tr><td align="left">Prateek Mishra</td><td 
align="left">Oracle</td></tr><tr><td align="left">Ron Monzillo</td><td 
align="left">Oracle</td></tr></tbody></table></div></div><div 
class="simplesect"><div class="titlepage"><div><div><h2 class="title" 
style="clear: both"><a 
name="preface4"></a>Keywords</h2></div></div></div><p>In this document, the 
keywords "MUST", "MUST 
+               NOT", "REQUIRED", "SHALL", "SHALL 
+               NOT", "SHOULD", "SHOULD NOT", 
+               "RECOMMENDED", "MAY", and "OPTIONAL" 
+               are to be interpreted as described in RFC 
2119.</p></div></div><div class="chapter"><div 
class="titlepage"><div><div><h1 class="title"><a 
name="overview"></a>Chapter�1.�Overview</h1></div></div></div><div 
class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span 
class="section"><a href="#overview.info.model">Information 
model</a></span></dt><dt><span class="section"><a 
href="#overview.services.model">Services model</a></span></dt><dt><span 
class="section"><a href="#overview.security.model">Security 
model</a></span></dt><dt><span class="section"><a 
href="#overview.programming.model">Programming 
model</a></span></dt></dl></div><p>This chapter provides a high level 
descripton of the 
+       information, service, security, and programming models of the Java 
+       Identity API.</p><div class="section"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="overview.info.model"></a>Information model</h2></div></div></div><p>The 
Identity Api adopts a simple model for network Identity, 
+               where <span class="emphasis"><em>Entities</em></span>, (i.e. 
persons, computers, 
+               services, documents, ...) are represented as collections of 
named, 
+               metadata qualified, values called <span 
class="emphasis"><em>Attributes</em></span>, 
+               where the <span class="emphasis"><em>metadata</em></span> is 
used to convey named 
+               property values, (e.g., issuer, validity period, usage 
constraints, 
+               ...) within the attribute representation.</p><p>An important 
feature of this simple model is that the attribute 
+               collection that corresponds to an entity is a stable 
container for 
+               which a durable, attribute-independent <span 
class="emphasis"><em>Entity 
+               Reference</em></span> may be formed to identify the 
collection without 
+               exposing the values of any attributes within the collection. 
+               Likewise, for the individual attributes within an entity, the 
model 
+               defines a value-independent <span 
class="emphasis"><em>Attribute Reference</em></span> 
+               form. Entity and attribute references allow for the privacy 
+               preserving exhange of handles to the corresponding artifacts; 
by 
+               retaining the ability to authorize access by the handle 
recipient to 
+               the corresponding identity values. The reference for an 
identity 
+               attribute is available from the Java representation of the 
attribute. 
+               Entity references are obtained by performing a <span 
class="emphasis"><em>
+               search</em></span> operation on an <span 
class="emphasis"><em>Attribute 
+               Repository</em></span> or <span 
class="emphasis"><em>Attribute Provider</em></span>. 
+               Attribute repositories and providers are described in 
+               <a class="xref" href="#overview.services.model" 
title="Services model">the section called &#8220;Services 
model&#8221;</a>.</p><p>Entity and Attribute References are composed of two 
+               parts:</p><div class="itemizedlist"><ul class="itemizedlist" 
style="list-style-type: disc; "><li class="listitem"><p>a <span 
class="emphasis"><em>Provider Lookup Context</em></span> that describes 
+                               the attribute repository from which the 
reference was obtained, and 
+                               thus at which it may used to obtain the 
corresponding entity or 
+                               attribute.</p></li><li 
class="listitem"><p>the repository specific data by which the referenced 
entity 
+                               or attribute may be located by the 
repository.</p></li></ul></div></div><div class="section"><div 
class="titlepage"><div><div><h2 class="title" style="clear: both"><a 
name="overview.services.model"></a>Services 
model</h2></div></div></div><p>The Identity Api defines an <span 
class="emphasis"><em>Attribute 
+               Service</em></span> as the point of governance and 
interaction with 
+               identity. The Identity Api also defines an attribute 
repository 
+               integration architecture which is applied within an attribute 
service 
+               implementation such that it serves as an integration point 
for 
+               distributed sources of identity. Sources of identiy are 
obtained from 
+               <span class="emphasis"><em>Repository Agents</em></span> that 
are registered within the 
+               attribute service. Each registration is represented by a 
<span class="emphasis"><em>
+               Repository Descriptor</em></span> that names the 
implementation class 
+               of the repository agent, and the name of the attribute 
repository 
+               registered with the agent.</p><p>Client applications interact 
with the <span class="emphasis"><em>Provider Lookup 
+               Service</em></span> of the attribute service to obtain an 
<span class="emphasis"><em>
+               Attribute Provider</em></span> corresponding to a provider 
lookup 
+               context. An attribute provider is a proxy that encapsulates 
the 
+               interfaces of an attribute repository, including such that 
they are 
+               protected as described in <a class="xref" 
href="#overview.security.model" title="Security model">the section called 
&#8220;Security model&#8221;</a>. 
+               The attribute repository maps the interfaces of the attribute 
+               repository interface to the interfaces and protocols of the 
+               underlying identity repository.</p><p>An Attribute provider 
interface features methods to acquire the 
+               attribute <span class="emphasis"><em>lookup</em></span> and 
<span class="emphasis"><em>update</em></span> 
+               service implementations from the attribute provider. In 
support of 
+               its lookup service, the attribute provider interface also 
supports a 
+               <span class="emphasis"><em>predicate</em></span>builder 
facility, which is used to 
+               construct entity and attribute <span 
class="emphasis"><em>selectors</em></span> for use 
+               in search operations at the lookup service. The update 
service of the 
+               attribute provider features methods to create entities, and 
to 
+               operate on existing entities and their contained attributes 
through 
+               their entity and attribute references.</p><p>As noted above, t
[truncated due to length]



[identity-api-spec commits] [identity-api-spec~git-docbook:ab754259] edits by prateek

monzillo 09/17/2013
 
 
Close
loading
Please Confirm
Close