Introducing JSR 351 - The Java Identity API

The Java JCP has approved a new JSR relating to the use of Identity information within Java. The JSR351 charter is:

To define application programming interfaces and identity interaction models that facilitate and control the use of identity by applications and in access control decisions.

Ron Monzillo gave a talk (presentation available here) at JavaOne on JSR 351, I'll paraphrase his presentation with some of the highlights here:

The proposal was supported by American Express, Aspect Security, Boeing, Ericsson AB, and OWASP. The Expert Group is composed of experts from IBM, Oracle, RedHat, SAP AG, and individuals active in the OWASP communtity. Companies and Individuals who would like to participate in the definition of this technology should visit the JSR page to join the Expert Group.

JSR Problem Statement:

The advent of social networking sites, the adoption of single-sign-on and identity federation services, and more generally, the increased use of the internet in conducting business, have combined to amplify the need for Java developers to be able to appropriately consume, produce, and safeguard the disclosure of network identity.

With an ever expanding set of applications being built on Java, entity definitions based on Identity credentials are not enough. New entity types such as "personal health record", "frequent flyer", are being used in ever increasing way to personalize services and impact security decisions offered within Java and Java applications.

Identity and personal information now comes from an increasingly diverse set of sources. No longer is authentication and personalization information coming from LDAP or SQL Databases, now it is coming from federated Identity Providers, from Social Graphs (e.g. Facebook, Twitter, LinkedIn, and other sources. Further, new federation and authorization models (e.g. OAuth2) are now becoming widespread. Developers face an ever increasing diversity of information sources, interaction methods, along with increased regulations and obligations on the use and protection of information particularly where it impacts personal privacy. While developers have had solutions for some time to deal with requirements of specific APIs and protocols, the growing requirement to support an evolving ecosystem of protocols and regulatory requirements suggests Java should evolve to provide a better foundational platform for Identity.

Proposal
The proposal focuses on 3 areas to:

• standardize representation of Identity,
• promote a standard attribute service, and
• standardize a declarative programming style.

This includes standardized attribute interfaces defining attribute names, handle multi-valued data, and handling meta-data such as date-of-issue, validity-period, privacy usage constraints, etc. The representation will also be defined in such a way that it will be compatible with the interfaces of the Java Security Model. Most importantly it represents Identity such that it can be more effectively and appropriately propagated between Java systems.

The common attribute service becomes a local point of reference for applications to:

• Encapsulate a diverse repository protocols and locations;
• optimize interactions with remote repositories;
• provide authoritative representation of source, validity, and other related meta-data; and,
• authorize and audit of application use of identity attributes in support of compliance with an Identity governance model.

The declarative programming style aims to provide:

• Client-side Java framework for consumption, generation, propagation, and governance of identity attributes
• Declaration of use, virtualization of source
• familiar to Java developers
• Dependency Injection replaces lookup
• Annotations declare dependencies
• AccessControlContext represents actors

The Reference implementation will be developed (not yet set up) as an open source Java.net project under the Apache 2.0 License. Target platforms are Java SE and Java EE beginning with Version 6.0. We also expect the product of this project to also be relevant to Java applications running in consumer appliances.

What Isn't In The Proposal:

• Standardization of a fixed set of identity attributes (i.e., a specific domain model) that Java developers should use
• That remains the responsibility of specific communities (e.g., citizens, finance, education, medicine) or application architects (e.g., CRM, HR,...)
• This JSR will:
• provide a domain model independent Java framework for representing and interacting with identity attributes.

For more details, check out Ron's presentation.