JSRs: Java Specification Requests
JSR 196: JavaTM Authentication Service Provider Interface for Containers
The following updates have been made to the original request.
2005.07.26: The JSR moved to JCP 2.6.
Original Java Specification Request (JSR)
Section 1. Identification
Submitting Member: Sun Microsystems
Name of Contact Person: Ron Monzillo
E-Mail Address: email@example.com
Telephone Number: +1 781 442 0968
Fax Number: +1 781 224 1610
Specification Lead: Ron Monzillo & Charlie Lai
E-Mail Address: firstname.lastname@example.org, email@example.com
Telephone Number: +1 781 442 0968, +1 408 276 7162
Fax Number: +1 781 224 1610, +1 408 276 7700
Initial Expert Group Membership:
Section 2: Request
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
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
JDK 2 SDK, Enterprise Edition, V 1.4 and above.
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.
The following dates are preliminary.
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.
Servlet Specification, version 2.4
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
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.
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.
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.