- Introduction
- A Simple Example
- Security Architecture
- User Authentication Requirements
- Authorization Requirements
- Deployment Requirements
- Future Directions
This chapter is from the book
This chapter is from the book
This chapter is from the book
J2EE.3.4 User Authentication Requirements
J2EE.3.4.1 Web Clients
The J2EE product provider must support several methods of web based user authentication.
J2EE.3.4.1.1 Web Single Signon
All J2EE compatible web servers must support single signon by maintaining a login session for each web user. This allows applications to remain independent of the details of implementing and securing login information. This also provides the J2EE product provider with the flexibility to choose authentication mechanisms independent of the applications secured by these mechanisms. It must be possible for one login session to span more than one application, allowing a user to log in once and access multiple applications.
J2EE.3.4.1.2 Login Sessions
All J2EE products must support login sessions as described in the servlet specification.
Lazy authentication must be supported by web servers for protected web resources. If authentication is required, then one of the three required login mechanisms listed in the next section may be used.
J2EE.3.4.1.3 Required Login Mechanisms
All J2EE products are required to support three login mechanisms: HTTP basic authentication, SSL mutual authentication, and form-based login. An application is not required to use any of these mechanisms, but they are required to be available for any application’s use.
HTTP Basic Authentication All J2EE products are required to support HTTP basic authentication (RFC2068). Platform Providers are also required to support basic authentication over SSL.
SSL Mutual Authentication SSL 3.0 2 and the means to perform mutual (client and server) certificate based authentication are required by this specification.
All J2EE products must support the following cipher suites to ensure interoperable authentication with clients:
-
SSL_RSA_EXPORT_WITH_RC4_40_MD5
-
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
These cipher suites are supported by the major web browsers and meet the U.S. government export restrictions.
Form Based Login The web application deployment descriptor contains an element that causes a J2EE product to associate an HTML form resource (perhaps dynamically generated) with the web application. If the deployer chooses this form of authentication (over HTTP basic, or SSL certificate based authentication), this form must be used as the user interface for login to the application.
The form based login mechanism and web application deployment descriptors are described in the Servlet 2.2 specification.
J2EE.3.4.1.4 Unauthenticated Users
Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. A web container reports that no user has been authenticated by returning null from the HttpServletRequest method getUserPrincipal.
The EJB specification requires that the EJBContext method getCallerPrincipal always returns a valid Principal object. It can never return null. However, it’s important that components running in a web container be able to call enterprise beans, even when no user has been authenticated in the web container. When a call is made in such a case from a component in a web container to an enterprise bean, a J2EE product must provide a principal for use in the call.
A J2EE product may provide a principal for use by unauthenticated callers using many approaches, including, but not limited to:
-
Always use a single distinguished principal.
-
Use a different distinguished principal per server, or per session, or per application.
-
Allow the deployer or system administrator to choose which principal to use.
This specification does not specify how a J2EE product should choose a principal to represent unauthenticated users, although future versions of this specification may add requirements in this area.
J2EE.3.4.2 Application Clients
To satisfy the authentication and authorization constraints enforced by the enterprise bean containers and web containers, the application client container must authenticate the application user. The techniques used may vary based on the implementation of the application client container and are beyond the control of the application. The application client container may integrate with a J2EE product’s authentication system, to provide a single signon capability, or the container may authenticate the user when the application is started. The container may delay authentication until it is necessary to access a protected resource or enterprise bean. If the container needs to interact with the user to gather authentication data, the container must provide an appropriate user interface. In this specification, no mechanism is provided to customize the user authentication interface of individual application clients. In a future version of this specification, application clients will be able to use the Java™ Authentication and Authorization Service APIs to access information about the currently authenticated user, to write portable authentication user interfaces, and to participate in and control the authentication process.
Application clients execute in an environment controlled by a J2SE security manager and are subject to the security permissions defined in Table J2EE.6-2, “J2EE Security Permissions Set.” Although this specification does not define the relationship between the operating system identity associated with a running application client and the authenticated user identity, a J2EE product’s ability to relate these identities is a fundamental aspect of single signon.
Additional application client requirements are described in Chapter J2EE.9 of this specification.
J2EE.3.4.3 Resource Authentication Requirements
Resources within an enterprise are often deployed in security policy domains that are different from the security policy domain to which the component belongs. Because the authentication mechanisms used to authenticate the caller to resources can vary widely, a J2EE product must provide the ability to authenticate in the security policy domain of the resource.
A product provider must support both of the following:
-
Specification of the principal and authentication data for a resource by the deployer at deployment time. A J2EE container must authenticate to the resource using the specified principal and authentication data; the application component must not need to provide this data. If the authentication data is stored by a J2EE container, then its confidentiality is the responsibility of the product provider.
-
Specification of the principal and authentication data for a resource by the application component at runtime using APIs appropriate to the resource. The application may obtain the principal and authentication data through a variety of mechanisms, including receiving them as parameters, obtaining them from the component’s environment, etc.