15.2 Authentication

 <  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.

[1] Identity assertion is the foundation of a general-purpose impersonation mechanism that makes it possible for an intermediary to act on behalf of an identity other than itself. An intermediary's authority to act on behalf of another identity may be based on trust by the target in the intermediary, or on trust by the target in a privilege authority that endorses the intermediary to act as proxy for the asserted identity. Identity assertion may be used by an intermediary to assume the identity of its callers in its calls.

15.2.1 Authentication Mechanisms

A 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

graphics/15fig02.gif

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 s

In 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 Information

A 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-On

Propagating 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.

  1. One way is to pass the credential as an HTTP cookie or part of the URL through a URL-rewriting mechanism. With this approach, the credential is sent back to the user, and the browser will send it back to the servers to which it sends requests. Servers can extract this information from the HTTP request, establish the requesting identity by validating the incoming credential, and authorize requests accordingly . If HTTP cookies are used, their configuration should consider the possibility of replay attacks, man-in-the-middle attacks, and so on. Using the Secure field of the cookie will ensure that such sensitive cookies are never transmitted in the clear but only over an HTTPS connection.

  2. An alternative approach in the case of J2EE is to store the credential in a javax.servlet.http.HTTPSession object. This approach has the advantage of letting the credential maintenance rely on the session maintenance and the infrastructure behind it. The disadvantage is that if a session is hijacked, the credentials inside it will be too.

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  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net