Skip to main content

[identity-api-spec commits] [identity-api-spec~git-docbook:db18e952] initial commit of generated html for EarlyDraft

  • From: monzillo@...
  • To: commits@...
  • Subject: [identity-api-spec commits] [identity-api-spec~git-docbook:db18e952] initial commit of generated html for EarlyDraft
  • Date: Mon, 16 Sep 2013 14:08:12 +0000

Project:    identity-api-spec
Repository: git-docbook
Revision:   db18e952eb3c10ae624cac65c934d589c013c034
Author:     monzillo
Date:       2013-09-16 13:59:47 UTC
Link:       

Log Message:
------------
initial commit of generated html for EarlyDraft


Revisions:
----------
db18e952eb3c10ae624cac65c934d589c013c034


Added Paths:
------------
EarlyDraft/dist/html/identity-api-spec-early-draft-01.html


Diffs:
------
--- /dev/null
+++ b/EarlyDraft/dist/html/identity-api-spec-early-draft-01.html
@@ -0,0 +1,574 @@
+<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>
+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
+following license, no part of the Specification may be reproduced in
+any form by any means without the prior written authorization of Oracle
+America, Inc. ("Oracle") and its licensors, if any. Any use of the
+Specification and the information described therein will be governed by
+the terms and conditions of this Agreement.</p><p>Subject to the terms and 
conditions of this license, including your
+compliance with Paragraphs 1 and 2 below, Oracle hereby grants you a
+fully-paid, non-exclusive, non-transferable, limited license (without
+the right to sublicense) under Oracle's intellectual property rights
+to:</p><p>1.Review the Specification for the purposes of evaluation. This
+includes: (i) developing implementations of the Specification for your
+internal, non-commercial use; (ii) discussing the Specification with
+any third party; and (iii) excerpting brief portions of the
+Specification in oral or written communications which discuss the
+Specification provided that such excerpts do not in the aggregate
+constitute a significant portion of the Technology.</p><p>2.Distribute 
implementations of the Specification to third parties for
+their testing and evaluation use, provided that any such
+implementation:</p><p>(i) does not modify, subset, superset or otherwise 
extend the Licensor
+Name Space, or include any public or protected packages, classes, Java
+interfaces, fields or methods within the Licensor Name Space other than
+those required/authorized by the Specification or Specifications being
+implemented;</p><p>(ii) is clearly and prominently marked with the word 
"UNTESTED" or
+"EARLY ACCESS" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of
+available builds and in proximity to every link initiating its
+download, where the list or link is under Licensee's control; 
and</p><p>(iii) includes the following notice:</p><p>"This is an 
implementation of an early-draft specification developed
+under the Java Community Process (JCP) and is made available for
+testing and evaluation purposes only. The code is not compatible with
+any specification of the JCP."</p><p>The grant set forth above concerning 
your distribution of
+implementations of the specification is contingent upon your agreement
+to terminate development and distribution of your "early draft"
+implementation as soon as feasible following final completion of the
+specification. If you fail to do so, the foregoing grant shall be
+considered null and void.</p><p>No provision of this Agreement shall be 
understood to restrict your
+ability to make and distribute to third parties applications written to
+the Specification.</p><p>Other than this limited license, you acquire no 
right, title or
+interest in or to the Specification or any other Oracle intellectual
+property, and the Specification may only be used in accordance with the
+license terms set forth herein. This license will expire on the earlier
+of: (a) two (2) years from the date of Release listed above; (b) the
+date on which the final version of the Specification is publicly
+released; or (c) the date on which the Java Specification Request (JSR)
+to which the Specification corresponds is withdrawn. In addition, this
+license will terminate immediately without notice from Oracle if you
+fail to comply with any provision of this license. Upon termination,
+you must cease use of or destroy the Specification.</p><p>"Licensor Name 
Space" means the public class or interface declarations
+whose names begin with "java", "javax", "com.oracle" or their
+equivalents in any subsequent naming convention adopted by Oracle
+through the Java Community Process, or any recognized successors or
+replacements thereof</p><p>TRADEMARKS</p><p>No right, title, or interest in 
or to any trademarks, service marks, or
+trade names of Oracle or Oracle's licensors is granted hereunder.
+Oracle, the Oracle logo, Java are trademarks or registered trademarks
+of Oracle USA, Inc. in the U.S. and other countries.</p><p>DISCLAIMER OF 
WARRANTIES</p><p>THE SPECIFICATION IS PROVIDED "AS IS" AND IS EXPERIMENTAL 
AND MAY
+CONTAIN DEFECTS OR DEFICIENCIES WHICH CANNOT OR WILL NOT BE CORRECTED
+BY ORACLE. ORACLE MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT
+THAT THE CONTENTS OF THE SPECIFICATION ARE
+SUITABLE FOR ANY PURPOSE OR THAT ANY PRACTICE OR IMPLEMENTATION OF SUCH
+CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADE
+SECRETS OR OTHER RIGHTS. This document does not represent any
+commitment to release or implement any portion of the Specification in
+any product.</p><p>THE SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR 
TYPOGRAPHICAL
+ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION THEREIN;
+THESE CHANGES WILL BE INCORPORATED INTO NEW VERSIONS OF THE
+SPECIFICATION, IF ANY. ORACLE MAY MAKE IMPROVEMENTS AND/OR CHANGES TO
+THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THE SPECIFICATION AT
+ANY TIME. Any use of such changes in the Specification will be governed
+by the then-current license for the applicable version of the
+Specification.</p><p>LIMITATION OF LIABILITY</p><p>TO THE EXTENT NOT 
PROHIBITED BY LAW, IN NO EVENT WILL ORACLE OR ITS
+LICENSORS BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST
+REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL,
+INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE
+THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING,
+PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF ORACLE
+AND/OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.</p><p>You will hold Oracle (and its licensors) harmless from any 
claims based
+on your use of the Specification for any purposes other than the
+limited right of evaluation as described above, and from any claims
+that later versions or releases of any Specification furnished to you
+are incompatible with the Specification provided to you under this
+license.</p><p>RESTRICTED RIGHTS LEGEND</p><p>If this Software is being 
acquired by or on behalf of the U.S.
+Government or by a U.S. Government prime contractor or subcontractor
+(at any tier), then the Government's rights in the Software and
+accompanying documentation shall be only as set forth in this license;
+this is in accordance with 48 C.F.R. 227.7201 through 227.7202-4 (for
+Department of Defense (DoD) acquisitions) and with 48 C.F.R. 2.101 and
+12.212 (for non-DoD acquisitions).</p><p>REPORT</p><p>You may wish to report 
any ambiguities, inconsistencies or inaccuracies
+you may find in connection with your evaluation of the Specification
+("Feedback"). To the extent that you provide Oracle with any Feedback,
+you hereby: (i) agree that such Feedback is provided on a
+non-proprietary and non-confidential basis, and (ii) grant Oracle a
+perpetual, non-exclusive, worldwide, fully paid-up, irrevocable
+license, with the right to sublicense through multiple levels of
+sublicensees, to incorporate, disclose, and use without limitation the
+Feedback for any purpose related to the Specification and future
+versions, implementations, and test suites thereof.</p><p>GENERAL 
TERMS</p><p>Any action related to this Agreement will be governed by 
California law
+and controlling U.S. federal law. The U.N. Convention for the
+International Sale of Goods and the choice of law rules of any
+jurisdiction will not apply.</p><p>The Specification is subject to U.S. 
export control laws and may be
+subject to export or import regulations in other countries. Licensee
+agrees to comply strictly with all such laws and regulations and
+acknowledges that it has the responsibility to obtain such licenses to
+export, re-export or import as may be required after delivery to
+Licensee.</p><p>This Agreement is the parties' entire agreement relating to 
its subject
+matter. It supersedes all prior or contemporaneous oral or written
+communications, proposals, conditions, representations and warranties
+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
+    avaialble at <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/index.html" ;
target="_top">http://identity-api-spec.java.net/nonav/1.0/apidocs/index.html</a>.
+    </p></div><div class="appendix"><div class="titlepage"><div><div><h1 
class="title"><a 
name="issues"></a>Appendix�A.�Issues</h1></div></div></div><p>This listitem 
of the document describes some areas in
+        which the Expert Group is working to improve the specification.
+    </p><div class="orderedlist"><ol class="orderedlist" type="1"><li 
class="listitem"><p><a name="issues.cursor"></a>Cursors to Manage Large 
Return Sets</p><p>The
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeLookupService.html#search(javax.security.identity.client.AttributeSelector...)"
 target="_top">search</a>
+                method of the AttributeLookupService Interface, returns a 
Collection of
+                EntityReference that satisfy at leats one of the argument 
Selectors. Depending
+                on the natur of the underlying identity repository, it may 
be inappropriate
+                to attempt to return the entire result set. As such the 
search method should
+                be augmented with an additional argument to define 
constraints on the acceptable
+                size of thet return set, and to allow a large set to be 
returned one chunk at a
+                time. A similar concern might be raised for
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeLookupService.html#getAttributes(javax.security.identity.IDEntityReference,%20javax.security.identity.client.AttributeSelector,%20javax.security.identity.client.PropertySelector...)"
 target="_top">getAttributes</a>
+                and
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeLookupService.html#getAttributeReferences(javax.security.identity.IDEntityReference,%20javax.security.identity.client.AttributeSelector,%20javax.security.identity.client.PropertySelector...)"
 target="_top">getAttributeReference</a>;
+                in which case the same argument should be added to the 
signatures of these
+                methods.
+            </p></li><li class="listitem"><p><a 
name="issues.unsupported.predicates"></a>Reporting Unsupported Predicate 
Operators</p><p>An attribute repository may not support all predicate 
operators,
+                and repositories that support the boolean predicate 
operators are unlikely
+                to support predicates formed from other predicates by 
repeated application
+                of the boolean predicate operators. Some predicates that a 
repository supports
+                in attribute searches performed in the context of a specific 
entity 
+                may not be supported in an entity search. Also an 
encapsulating attribute provider
+                could provide support for attribute searches that are not 
supported by the 
+                encapsulated attribute repositories or providers. Givne 
these considerations,
+                the predicate builder aspect of the 
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeRepository.html";
 target="_top">AttributeRepository</a> 
+                and
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html";
 target="_top">AttributeProvider</a>
+                interfaces, and the predicate based methods of the 
corresponding
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/RepositoryLookupService.html";
 target="_top">RepositoryLookupService</a>
+                and 
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeLookupService.html";
 target="_top">AttributeLookupService</a>
+                need to be improved to convey failures resulting from 
unsupported predicates.
+            </p></li><li class="listitem"><p><a 
name="issues.limited.search"></a>Layering Predicate Based Search over Social 
Repositories</p><p>There are various impediments to reconciling the generic, 
predicate-based
+                search defined by the API with the lookup facilities 
provided by the various
+                social repositories. Among those impediments are:
+            </p><div class="itemizedlist"><ul class="itemizedlist" 
style="list-style-type: disc; "><li class="listitem">the mismatch between the 
rich calculus of concrete predicates,
+                    and specialized and highly optimized search semantics 
implemented
+                    by the social repositores
+                </li><li class="listitem">the patitioning of the searchable 
repository space based on
+                    the authentications state of the party doing the search
+                </li></ul></div><p>As such it seems most practical to apply 
predicate based search to
+                a virtual repository (sometimes referred to as a Connector 
repository)
+                obtained by using a repository specific query to constrain
+                the entity space to some internalizable set of entities, 
such that the
+                predicate based search can be applied to the internalized 
entities.
+            </p><p> We had previously arrived at this same conclusion for 
the processing
+                of Property Selectors.
+            </p></li><li class="listitem"><p><a 
name="issues.durable.refs"></a>Defining Durable References to Enities in 
Connector Repositories</p><p>If we assume, including for the reasons 
described in
+                <a class="xref" href="#issues.limited.search">3</a>,
+                that we will employ Connector Repositories to integrate 
subsets of external 
+                repositories into the Attribute service, then we must define 
how we will
+                convey and process references to the internalized entities 
and attributes.
+                References to Attributes and Entities contain a
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/client/ProviderLookupContext.html";
 target="_top">ProviderLookupContext</a>
+                that conveys the information that allows the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/client/ProviderLookupService.html";
 target="_top">ProviderLookupService</a>
+                of the Attribute service to obtain an instance of an 
AttributeProvider 
+                from which the referenced attributes can be obtained. In 
addition to their
+                contained ProviderLookupContext the reference objects carry
+                additional provider specific information that is 
interepreted by the attribute
+                provider to locate the corresponding entity (a collection of 
attributes) or
+                attribute. The combination of ProviderLookupContent and the 
the provider
+                specific information within the reference, must be 
sufficient for the
+                AttributeProvider instance obtained for the 
ProviderLookupContext, to
+                obtain the corresponding entity or attribute from the 
physical
+                repository, and this combined information should be durable 
such that a 
+                reference is valid for as long as the correponding entity or 
attribute
+                exists and is available from the backend repository.
+            </p><p>Moreover, The ProviderLookupContext would be expected to 
convey a
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/client/RepositoryDescriptor.html";
 target="_top">RepositoryDescriptor</a>
+                which would internally name the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/RepositoryAgent.html";
 target="_top">RepositoryAgent</a>
+                by className, along with a String identifying the provider 
instance to be 
+                obtained from the Agent. If, given a ProviderLookupContext, 
the
+                ProviderLookupService is to return an AttributeProvider that 
has internalized
+                the same set of entities as the provider from which a 
reference was obtained,
+                then the information in the provider identifcation String 
must be sufficient
+                for the RepositoryAgent to be able to return an 
AttributeProvider that is
+                capable of dereferencing the provider specific reference 
information and
+                returning the proper attributes. With the exception of an 
entity reference
+                to an internalized subset containing exactly that one 
entity, being able to
+                deference a specific entity or attribute reference would not 
require that
+                the RepositoryAgent be able to internalize the entire subset 
of entities
+                that were internalized by the attribute provider from which 
the reference
+                was obtained; however that would mean that we could not 
longer assume that
+                AttributeProviders returned for the same 
ProviderLookupContext provide
+                access to a common repository of entities (virtual or 
otherwise). To sustain
+                that assumption, the combination of the information
+                contained in a RepositoryDescriptor and the class definition 
for the
+                referenced RepositoryAgent must be sufficient to achieve 
that effect.
+                As such, it may be necessary to enhance the definition of 
the RepositoryDescriptor
+                class to allow it to carry addional subset identifying 
information. Note that any
+                such chnage would require a corresponding change to the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/permission/AttributeRepositoryPermission.html";
 target="_top">AttributeRepositoryPermission</a>.
+            </p></li><li class="listitem"><p><a 
name="issues.layering.protection"></a>Layering the Service Protection 
Model</p><p>An attribute service is minimially an implementation of the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/client/ProviderLookupService.html";
 target="_top">ProviderLookupService</a>.
+                From the ProviderLookupService, a client application may 
obtain implementations of the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeProvider.html";
 target="_top">AttributeProvider</a>
+                interface which offer a predicate building service, along 
with access to the
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeLookupService.html";
 target="_top">AttributeLookupService</a>
+                and
+                <a class="ulink" 
href="http://identity-api-spec.java.net/nonav/1.0/apidocs/javax/security/identity/provider/AttributeUpdateService.html";
 target="_top">AttributeUpdateService</a>
+                interfaces of the AttributeProvider.
+            </p><p>In addition to its role in providing access to integrated 
attribute
+                providers, the attribute
+                service is required to enforce requied permission checks on 
the methods
+                of the ProviderLookupInterface, and to return 
AttributeProvider implementations
+                that enforce required permission checks on the methods of the
+                AttributeProvider interface and of the Lookup and Update 
service implementations
+                returned from the AttributeProvider implementation. These 
permission checks
+                constrain access to the service interfaces of the attribute 
service and of its
+                contained attribute providers. The attribute service
+                performs this service protection on behalf of its integrated 
providers,
+                both to ensure that the protection is always applied 
independent of the
+                implementation of the integrated providers, and to ensure 
that access
+                checks can be performed in advance of operations that may 
span multiple
+                integrated providers.
+            </p><p>The role of the attribute service in layering a service 
protection model
+                over the integrated attribute providers, suggests that the 
attribute service
+                implement a different (i.e., augmented with access control 
ckecking
+                requirements) interface from that implemented by the 
integrated attribute
+                providers.
+            </p></li><li class="listitem"><p><a 
name="issues.obtaining.creds"></a>Obtaining Repository Specific Client 
Credentials</p><p>An AttributeProvider may require repository specific 
credentials in order to
+                interact with the repository. Minimally this specification 
needs to define
+                an interface or contract by which the credentials needed by 
the provider to
+                access the remote repository, can be acquired by the 
provider. For cases
+                where the attribute service is processing requests on behalf 
of muliple users
+                (including the case where the attribute service is being 
used by a service
+                such as a web service embedded in an application server), 
the provided interface or
+                contract must be capable of differentiating the separate 
user contexts and
+                of obtaining repository specific credentials corresponding 
to a specific
+                user context. Some repositories may require authentication 
(of the user)
+                and/or authorization of the attribute provider by the user, 
such that the
+                provider is authorized to access some aspect of the user's 
identity
+                resources within the repository. In some cases, this 
authentication and
+                authorization must occur in the context of the attribute 
provider's access
+                to the repository, in which case, the specification must 
define interfaces
+                and or contracts by which an attribute provider caan engage 
the attribute
+                service user, or the user of some service which is employing 
the attribute
+                service (on the user's behalf) in an authentication and 
authorization
+                dialog with some facilities of the backend repository.
+            </p></li><li class="listitem"><p><a 
name="issues.policy.control"></a>User Authorization of Access to 
Identity</p><p>The specification seeks to define interfaces to allow users to
+                authorize disclosure and use of their identity attribut
[truncated due to length]



[identity-api-spec commits] [identity-api-spec~git-docbook:db18e952] initial commit of generated html for EarlyDraft

monzillo 09/16/2013
 
 
Close
loading
Please Confirm
Close