The Java Community Process(SM) Program - JSRs: Java Specification Requests

BEA Systems
Hewlett-Packard
Netegrity Inc.
Novell Networks
RSA Security
Sun Microsystems, Inc.

2.1 Please describe the proposed Specification:

The proposed specification will define a standard service provider interface by which authentication mechanism providers may be integrated with containers. Providers integrated through this interface will be used to establish the authentication identities used in container access decisions, including those used by the container in invocations of components in other containers. The specification will define standard interfaces between containers and authentication modules to support the following interactions:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

2.3 What need of the Java community will be addressed by the proposed specification?

Although the J2EE platform requires that containers support a rich set of widely available authentication standards, no standard mechanisms are defined by the platform that provide for the integration of the required mechanisms with external service providers or user registries. Moreover, differences in container integration interfaces and associated capabilities serve to complicate the widespread integration of common, robust, and interoperable implementations of authentication functionality. The proposed specification would ensure that any J2EE compatible container may be integrated with authentication infrastructure encapsulated in an authentication module conforming to the specification. This evolutionary capability will provide additional justification for platform adoption including by empowering container vendors, system integrators, and security vendors to respond more efficiently to container integration opportunities.

2.4 Why isn't this need met by existing specifications?

The J2EE platform sought to define container services without overly defining or unnecessarily constraining a container's implementation of these services. This strategy served the Platform well during the period where required services could be predicted and requirements for new services could be easily accommodated within the platform release cycle. The increased focus on security and the rapid introduction of new security standards and services is necessitating a more fundamental ability to evolve the common definition of the J2EE Platform.

2.5 Please give a short description of the underlying technology or technologies:

The J2EE Servlet and EJB containers serve as an authentication boundary between callers and container hosted components. In order for a caller to gain access to an authentication protected component, the caller must be able to authenticate as an identity known to the container and mapped to the application.

The J2EE platform defines an application programming, packaging, and deployment paradigm which ensures that J2EE applications will be portable to diverse, vendor provided, runtime environments. This paradigm features a declarative methodology for capturing the security requirements of applications and an ability to satisfy these requirements at deployment using mechanisms and infrastructure of the application's runtime environment.

The J2EE platform requires support for standard interoperability protocols to ensure that compatible containers can securely interoperate with containers from other vendors. Containers support authentication mechanisms in their validation of credentials arriving with incoming invocations and in their use of the identity established for a component in requests made by the component to other components over interoperable protocols.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 Are there any security issues that cannot be addressed by the current security model?

2.9 Are there any internationalization or localization issues?

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

2.11 Please describe the anticipated schedule for the development of this specification.

Expert Group Formed: Nov. 2002
Community Draft Submitted to PMO: Mar. 2003
Public Draft Submitted to PMO: June 2003
Proposed Final Draft Submitted to PMO: Aug. 2003

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

We will schedule periodic expert group teleconferences and exchange issues and resolutions on an archived email list. We may also schedule face-2-face meetings of the the expert group as appropriate.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Java Servlet Specification, version 2.4
Enterprise Java Beans Specification, version 2.1
Java 2 Platform Enterprise Edition specification, v1.4
User authentication in J2SE, version 1.4, Reference Guide
Corba 2.6 Secure Interoperability (CSiv2)
OASIS Web Services Security Specification

Liberty Bindings and Profiles Specification

3.2 Explanation of how these items might be used as a starting point for the work.

The Servlet, EJB, and J2EE platform specifications define the authentication functionality required in containers, as well as the responsibilities of application developers, assemblers, deployers, and platform providers. The requirement for an authentication SPI was captured in discussions with our security partners and has been a recurring theme in subsequent discussions with J2EE container providers, system integrators, and security providers.

The Specification of User Authentication in J2SE, is expected to provide the API used to establish a client security context in a component. The JAAS API described in this document is expected to serve as the basis of the interfaces defined by this specification.

The OASIS Web Services Security Specification and its related bindings to specific security tokens (i.e. SAML assertions, Kerberos service tickets, and X509 Certificates) is resulting in the standardization of SOAP authentication mechanisms to be integrated with J2EE containers that host or invoke web services endpoints.

The Liberty Bindings and Profiles specification profiles the use of the Liberty SSO protocol over HTTP, and provides an example of an authentication mechanism to be integrated with J2EE Servlet containers.

The CSIv2 specification defines the secure interoperability protocol used for EJB invocations.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition

In the J2EE programming model, a component's client side security context is established by the deployer such that the component either depends on the container to impersonate its caller, or the component runs with a static login context established when the component was deployed. Only in resource manager mediated interactions, does the J2EE programming model define how a component's client security context can be established by the running component.

As part of its work in defining an SPI for container authentication, the expert group will consider extending the J2EE security model to allow components to use the interfaces defined or enabled by this specification to define the client side login context used by a component in the container mediated operations it performs. In effect, such components would be acting as container authentication modules.

The J2EE programming model does not define standard APIs that may be used to cause container visible user accounts to be created from the portable component programming model. Discussions with Servlet developers and the experiences of those who developed the Petstore application, as described in "Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition), have indicated a requirement that users be able to interact with components to cause the registration of their container authentication identities. Since any authentication identities established from the component programming model must be integrated with the authentication modules employed by the container, this specification will also consider opportunities to define standard APIs to provide for the portable registration of container authentication identities, especially as necessary to ensure appropriate integration with container authentication modules.