< Day Day Up > |
The purpose of authentication is to verify the identity of a requesting entity. Typically, this entity is an end user requesting access to a resource, such as a URL or an enterprise bean. Authentication in enterprise environments may also include authenticating other entities, such as servers. For example, in order to trust a Web container, an EJB may end up authenticating an identity associated with the Web container. The process of authentication involves verifying the authentication data provided by an identity. Authentication data may be a user ID and password pair or a security credential, such as an X.509 certificate, a Kerberos ticket, or other forms of acceptable credentials. Based on the security level of an environment, identity may also be asserted. [1] In such cases, the validity of the assertion will be based on the trust relationship between the asserting authority and the validating end point.
15.2.1 Authentication MechanismsA J2EE container's authentication framework typically consists of an authentication mechanism and a user registry (see Figure 15.2). The authentication mechanism is responsible for processing authentication data. The result of this process is a set of authenticated credentials. Depending on the type of authentication mechanism and the authentication data, the authentication mechanism may in turn consult a user registry to verify the authentication data. For example, if the authentication data is a user ID and password pair and if the user registry is an LDAP directory, the authentication mechanism will verify the password by performing an LDAP bind against the directory. A successful authentication will result in a set of authenticated credentials. If Kerberos is an authentication mechanism, the resultant credential will be a Keberos ticket. Figure 15.2. The Process of Authentication
Considering the flow of request given in Figure 15.1 on page 528, the user ID and password will be validated by the Web container. On successful authentication, the credential ”for example, a Kerberos ticket ”will be propagated for the downstream requests . When the request is handled by the EJB container, it will perform authentication by validating the Kerberos ticket. 15.2.2 Using JAAS LoginModule sIn a Java environment, the implementation of an authentication mechanism can be realized through one or more login modules, implemented in JAAS as objects of type javax.security.auth.spi.LoginModule (see Chapter 9 on page 289). WASs can use the JAAS framework to authenticate a set of credentials through a login module. The result of a login is a JAAS subject, implemented as an object of type javax.security.auth.Subject . The authenticated credential can be part of the Subject that is returned from the LoginModule . Using JAAS LoginModule s allows for an extensible framework so that any LoginModule can be plugged into the container environment and possibly even be stacked with other LoginModule s. In the context of CSIv2, enough information needs to be propagated from one container to another so that an identity can be established within the second container. In this case, a credential from a JAAS Subject can be extracted and serialized as a security token for use by the CSIv2 protocol. On the receiving end, a Subject can be reconstructed by validating the incoming token, using the configured LoginModule . This approach allows LoginModule s to be used for authentication and validation, thus facilitating authentication and delegation in a secure end-to-end request flow. 15.2.3 User InformationA J2EE container is responsible for answering the queries through the J2EE APIs, such as the EJB methods isCallerInRole() and getCallerPrincipal() , and the servlet methods isUserInRole() and getUserPrincipal() . In the case of getCallerPrincipal() and getUserPrincipal() , the object to be returned is a java.security.Principal . Applications using this mechanism to obtain the user name call the getName() method on the returned Principal object. The container should return a user name that is useful for the application. For example, when using an LDAP directory for authentication, getName() should return the Distinguished Name of the user. As enterprise environments may consist of multiple user registries, it may also be useful to provide a user name qualified by the name of the security domain. 15.2.4 Single Sign-OnPropagating identity to downstream servers allows user identity to be available to applications accessed within a call chain. In the case of HTTP, many Web applications can be hosted in different Web containers. In such scenarios, the Web containers are required to provide a mechanism to maintain user identity across HTTP requests. If the same credential is made available across requests to Web containers, a user will not be prompted more than once for authentication data. This addresses the need for single sign-on for HTTP requests. User idenity across HTTP request can be maintained in at least two ways.
Maintaining application-state information (session) independent of authentication-state information (credential) makes it possible to achieve SSO across J2EE and non-J2EE applications as well. It is also desirable to span multiple application sessions across a single authentication state and vice versa. This enables the HTTP session timeout to be independent of the authentication credential timeout. Therefore, it is advantageous to have the ability to maintain HTTP session state information and authentication state information independently of each other. |
< Day Day Up > |