Before I jump into the nitty-gritty, let’s take a look at some of the quick facts about Java Identity API JSR 351. This is still a work in progress . . .
- When was the JSR initiated?
This JSR passed the Approval Ballot in October 2011 which was followed by Expert Group formation in November 2011.
- Who is leading this specification?
The Java Identity API is being lead by Ron Monzillo.
- Expert Group?
The EG consists of representatives from Oracle, IBM, RedHat, SAP and GoldmanSachs as well as individuals.
- Specification document?
This is still in a draft phase and is available at: https://jcp.org/aboutJava/communityprocess/edr/jsr351/index.html
- Reference Implementation
Nobis is the RI for the Java Identity API and can be accessed at: https://java.net/projects/nobis/pages/Home
If I had to explain the motive behind the Java Identity API in a single line, it would be defined as, a Java standard for Identity Management.
On a high level, the primary goals of this standard are:
- Define a representation for an Identity in Java.
- Facilitate secure usage (creation, exchange, governance) of these ‘identities’ by defining a Standard API and Interaction models between Identity consumers and providers.
- Provide a uniform, high level programming model for application to interact with identity/attribute repositories with heterogeneous domain models.
Currently, the Java Platform does not provide standard interfaces for managing identities. With the increasing use of internet services in day to day applications, adoption of SSO and federation, there is a need to protect network identity. Existing Java objects, such as the X509Certificate and KerberosTicket provide semblance for encapsulating identity attributes, but only to a limited extent. Instead of having disparate and non standard model, there is a requirement for a set of standards to evolve, which can be leveraged by application or identity framework developers to provide rock solid support for propagation and consumption of network identity.
A Simple Analogy
I like to think of it as an API similar to JDBC or JNDI (if not the same). Both these APIs, help developers communicate with underlying data sources or naming services in a loosely coupled fashion through standard interfaces. It allows us to adopt a pluggable architecture wherein different vendor implementations can be leveraged to connect disparate databases (be it Oracle, MySQL, Sybase DB2 . . we really do not care apart from having the vendor JARS in our class path), LDAP servers (AD, OID, Sun Java, Apache etc).
How can the Java Identity API help?
This API will:
- Allow applications to interact with heterogeneous underlying identity repositories in a portable and standard fashion.
- Allow vendors to develop implementations using the Attribute Service framework to seamlessly interact with attributes in one or more repositories e.g. Facebook, Twitter, Linked in via supported protocols/APIs such as OAUTH, Open ID, FaceBook Connect etc.
- Enable applications to also act as providers of attributes – this is also a part of the Attribute Service framework.
- Allow the end developers to build applications on top of these implementations.
- Prevent dependency upon non standard, proprietary implementations to implement identity services within applications.
Some of the key features/highlights of this API have been listed below:
- Compatibility with Java SE 6 and Java EE 6
- Integration with the Java Security model
The existing objects within the Java Security model like Principal, Subject, Policy etc will be integrated within the API:
- Support for Programmatic as well as Annotation driven programming models
- Leveraging Contexts and Dependency Injection (CDI)
CDI will render services such as resource injection, life cycle callbacks and of course dependency injection of identity attributes and references within applications via Qualifiers and Producers.
A brand new specification can often introduce terms or expressions which might sound vague or abstract at first. Here is a list of keywords and concepts which are intimately attached to the Java Identity API. Having a basic understanding of these terminologies is important.
|Entity||Nothing but collection of ‘Attributes‘ e.g. A Person can have attributes such as First Name, Last Name, SSN, Email etc.|
|Attribute||It has a name (username, email), value (johndoe, firstname.lastname@example.org) and associated metadata (issuer, expiry)|
|Entity Reference||A secure handle for an entity|
|Attribute Reference||A secure, value independent handle to the Attribute itselfNote: Both Entity and Attribute references facilitate exchange without actually exposing the associated value|
|Attribute Repository||Represents a set of contracts to be implemented in order to integrate with an identity source. Contains the business logic to interact with the end identity repository|
|Repository Agent||It’s bound to a specific Attribute Repository and can be queried to provide a handle to the Attribute Repository it is attached to|
|Repository Descriptor||Describes the relationship b/w a Repository Agent and the Attribute Repository which is bound to the agent|
|Attribute Provider||Interacts with the Repository Agent and acts on its behalf to perform operations requested by the consumer|
|Attribute Service||It’s a service component which is exposed directly to the client application. It provides access to high level interfaces for interacting with and managing identities|
The Java Identity API is fairly lightweight and compact. The packages which form a part of the core programming interface have been highlighted below.
|javax.security.identity||This package contains the identity attribute and reference types|
|javax.security.identity.annotations||Contains annotations which help provide a portable identity programming model|
|javax.security.identity.auth||Contains identity attribute and reference types for use in a Java Subject or AccessControlContext.|
|javax.security.identity.client||Provide high-level programming interfaces to the identity attribute services.|
|javax.security.identity.client.expression||Contains provider-independent expressions that are used to compose attribute queries.|
|javax.security.identity.client.qualifiers||Defines annotations to be used as qualifiers in CDI injection of Identity attributes.|
|javax.security.identity.permission||Consists of the permission and actions values used to protect the interfaces of the attribute service.|
|javax.security.identity.provider||Contains interfaces that are to be implemented by attribute providers and repository agents.|
Some of the important annotations, interfaces and classes of the Java Identity API have been highlighted below:
Interfaces and Classes
|Attribute Repository||javax.security.identity.provider. AttributeRepository|
High Level Overview of API Usage
Applications need access to underlying repositories to interact with them and perform operations. The below example outlines the sequence of steps highlighting the ways in which an application can leverage the API to obtain handles to the underlying identities and attributes:
- Concrete implementation of the javax.security.identity.client.LookupService interface. This encapsulates the services of javax.security.identity.client.ProviderLookupService and the javax.security.identity.provider.AttributeLookupService
- An instance of the javax.security.identity.client.ProviderLookupContext is obtained as a result of binding the LookupService with an implementation of the javax.security.identity.provider.RepositoryAgent
- The ProviderLookupContext is used to get a reference to javax.security.identity.provider.AttributeProvider that is bound to the range of entities contained in the repository identified by the ProviderLookupContext.
- The AttributeProvider implementation is the gateway to the underlying identity repository and exposes CRUD like functionality via the javax.security.identity.provider.RepositoryLookupService and javax.security.identity.provider.RepositoryUpdateService
As with most Java standards, JSR 351 has a reference implementation known as Nobis. It provides implementations for:
- javax.security.identity.client.LookupService i.e. the ProviderLookupService and AttributeLookupService – to enable search/lookup identity attributes from the repository
- javax.security.identity.client.IDPredicate – serves as a filtration/search criteria
As a part of the implementation, the Nobis RI also provides:
- Post Construct Interceptors corresponding to the @javax.security.identity.annotations.IDEntityProvider and @javax.security.identity.annotations.IDEntity, which are nothing but Interceptor Bindings.
- A factory like API equivalent for above mentioned Interceptors
- A sample implementation of Facebook as an Attribute Provider along with JPA based and in-memory providers.
Some things to look forward to
- How is the API going to evolve and attain final shape
- How will it be adopted by the community
- How would this be implemented and leveraged by products and real world applications
Cheers . . . . ! ! !