4.5 Authentication

Authentication is the process to prove the identity of an entity or principal. In a J2EE environment, a principal may be

• An end user ”for example, Bob ”invoking a J2EE component

• A WAS ”for example, a server hosting a finance application ”delegating a request downstream to another WAS

• A WAS that has to access a resource adapter ”for example, a JDBC connector ”using a resource-specific connection pattern (see Section 3.4 on page 61)

• Any combination of the preceding

The requests to access Web resources are submitted as HTTP requests . Therefore, the means of authentication are tied to HTTP capabilities, with certain enhancements introduced at the J2EE Web application layer.

4.5.1 Login-Configuration Policy

In order to authenticate the caller, authentication data needs to be retrieved so that it can be used to perform the authentication. The authentication data ”for example, user ID and password ”can be retrieved in many ways. In the case of HTTP, it is possible to use the HTTP authentication mechanism, whereby user ID and password are expected in a specific HTTP header. Because the HTTP authentication mechanism does not involve a user-friendly HTML form, J2EE allows for an enhanced mode by which the user ID and password can be sent to the WAS. As part of the login-configuration details of a J2EE Web application, an Application Assembler and/or a Deployer can specify the approach by which a user's authentication data should be obtained. This is done in the deployment descriptor, web.xml , bundled in the Web application's WAR file. The authentication method is specified through the auth-method element in the login-config descriptor. The auth-method element indicates which authentication mechanism should be used to obtain the authentication data.

As we saw in Section 3.9.1.1 on page 78, there are three types of authentication methods :

1. HTTP. The credentials submitted by the client are user ID and password, transmitted as part of an HTTP header. The HTTP authentication method can be either basic or digest. With basic authentication, the user ID and password are sent as cleartext (see footnote 2 on page 77). For this to happen, the auth-method element in the login-config descriptor must be set to BASIC . With digest authentication, the user ID is sent in cleartext, but for security reasons, only a hash value of the password is transmitted to the server. For this to happen, the auth-method element in the login-config descriptor must be set to DIGEST .

   With HTTP standard authentication, it is also necessary to specify a realm name . This is done by setting a value for the auth-method element in the login-config descriptor. Recall that realms are used to determine the scope of security data and provide a mechanism for protecting Web application resources. The realm name indicates the HTTP security realm for which the user ID and password should be supplied and typically has a significance about the security registry against which an authenticating user must be verified . For example, a value of HRDept would mean that the user ID and password must be valid in a registry that is associated with the enterprise's human resources (HR) department. Section 4.5.1.1 describes how the realm name is used in HTTP authentication.

2. Form based. With form-based authentication, the credentials required of a user are user ID and password. A user submits these credential from within an HTML form. Form-based authentication requires that the auth-method element in the login-config descriptor be set to FORM . The form-login-config element in the login-config descriptor indicates the URL of the Web page containing the login HTML form and the URL of an error page to which the user will be redirected if the authentication fails.

3. Certificate based. If a user is to be authenticated using client-side X.509 certificates (see Appendix B on page 553), the auth-method element in the login-config descriptor must be set to CLIENT-CERT .

The following subsections describe each of these authentication methods in detail.

4.5.1.1 HTTP Authentication Method

The specification for HTTP authentication is described in Request for Comments (RFC) 2617. ^[1] The two modes of HTTP authentication ”basic and digest ”are implemented by HTTP. Therefore, when an HTTP client, such as a Web browser or a Java program, authenticates itself to an HTTP server, the communication between the client and the server is based on the HTTP specification.

^[1] See http://www.ietf.org/rfc/rfc2617.txt.

When the HTTP authentication mode is basic, the user ID and password of the end user are submitted in cleartext as part of an HTTP header. When a client submits a request without the authentication data, a server that has been configured to perform basic authentication responds by indicating that this type of authentication is required. The client must resubmit the request with a user ID and password pair. A typical HTTP communication flow with basic authentication request is summarized in Figure 4.4.

Figure 4.4. Communication Flow with HTTP Basic Authentication

Suppose that the www.fabrikam456.com Web site hosts travel reservations online. When a user visits the site to make reservations , the client submits a request to http://www.fabrikam456.com/travel/reserve . The Web site has secured access to reservations by means of HTTP basic authentication. Therefore, the Web server receiving the request will send an error response indicating that basic authentication is required. The client will be asked to submit authentication data relative to a user registry, which is specified in terms of an HTTP security realm.

It is possible for an end user to have accounts in multiple security realms. Therefore, in order to help the end user provide a valid user ID and password for the target realm, the Web server will also indicate a realm name when it issues an authentication response. In HTTP terminology, the Web server sends back an HTTP 401 error code. Along with the error code, the server sends back a WWW-Authenticate HTTP header, asking the client to authenticate with basic authentication by submitting a valid user ID and password pair specific to a named realm. In the scenario depicted in Figure 4.4, the server issues an HTTP 401 response with an HTTP WWW-Authenticate header, indicating that the server expects basic authentication specific to the fabrikam456 HTTP realm.

A WAS can be configured to protect a Web resource with HTTP basic authentication by setting the auth-method element in the login-config descriptor to BASIC . The name of the realm to which the user must authenticate must be specified by setting the realm-name element. A sample login configuration for basic authentication requiring a user to authenticate to the fabrikam456 realm is shown in Listing 4.3.

Listing 4.3. Sample Login Configuration for HTTP Basic Authentication

 <login-config>    <auth-method>BASIC</auth-method>    <realm-name>fabrikam456</realm-name> </login-config> 

On receiving an HTTP 401 error response from a Web server, a Web browser prompts the user for a user ID and password in a dialog box, which also shows the realm name. In the context of the scenario of Figure 4.4, the user is prompted for user ID and password for the fabrikam456 realm.

When the client responds with a user ID and password, the original request ”for example, http://www.fabrikam456.com/travel/reserve ”must also be resubmitted. The authentication information is sent over as an HTTP header named Authorization . The client sends a base64-encoded version (see footnote 2 on page 78) of the user ID and password, with a colon separating these two values. For example, if user Bob Smith has user ID bob and password bobpass , the base64 encoding of the string bob:bobpass will be computed and sent as an authorization header.

As discussed in Section 4.10.2 on page 149, HTTP is a stateless protocol. Therefore, the WAS processes this request as if it were a new request. The WAS will find out that the URL is protected and that it requires HTTP basic authentication. The WAS will then look for the Authorization HTTP header in the submitted request to find the userID and password information. The server extracts the user ID and password from the header by decoding the base64-encoded value and validates the values within the specified realm. In the example of Figure 4.4, the server validates the user ID and password pair in the frbrikam456 realm. If the values are correct , the client will be considered to have been successfully authenticated. If not, the WAS responds with an error message.

Because the user ID and password are encoded in base64 format, which from a security point of view is equivalent to cleartext, it is highly recommended that this transaction take place over an SSL connection (see Chapter 13 on page 449). Specifically, whenever user ID and password will be sent in response to an HTTP 401 challenge, the request is recommended to be an HTTP over SSL ( HTTPS ) request. ^[2] For example, in the scenario depicted in Figure 4.4, the URL invoked by the client would be https://www.fabrikam456.com/travel/reserve . In J2EE, one can require basic authentication to be sent over a secure channel, as explained in Section 4.6.6 on page 133.

^[2] With HTTP basic authentication, the credentials required of the client for authentication are user ID and password. Therefore, SSL is not used to authenticate the client but only to protect the communication between the client and the server. For this reason, it is not necessary for the server to require mutual-authentication SSL. Typically, in these scenarios, user ID and password information is transmitted over an SSL session with server-side authentication only.

With digest authentication, the user ID and a hash value of the password (see Section 10.2.2.4 on page 356) are transmitted to the HTTP server as part of an HTTP header. This way, the password does not appear in cleartext, which is the biggest weakness of basic authentication.

The details of how digest authentication works are explained in Chapter 3 on page 55. The authentication flow in digest authentication is similar to that in basic authentication mode. With digest authentication, however, the WWW-Authenticate HTTP header indicates that the HTTP server expects digest authentication.

As we observed in Chapter 3 on page 55, in order for an HTTP server to compute the hash value of a user's password, the server must have access to the passwords of all the users. This is rarely the case in most enterprise environments, as passwords in cleartext are not retrievable from a user repository containing user ID and password information. Therefore, digest authentication has not been widely adopted in enterprise environments and hence is not required to be supported by a J2EE container.

A WAS that supports digest authentication can be configured to protect a Web resource with HTTP digest authentication by setting the auth-method element in the login-config descriptor to DIGEST . The name of the realm to which the user must authenticate must also be specified by setting the realm-name element. A sample login configuration for digest authentication requiring a user to authenticate to the fabrikam456 realm is shown in Listing 4.4.

Listing 4.4. Sample Login Configuration for HTTP Digest Authentication

 <login-config>    <auth-method>DIGEST</auth-method>    <realm-name>fabrikam456</realm-name> </login-config> 

4.5.1.2 Form-Based Authentication Method

A user-friendly presentation layer is a key part of an enterprise's e-business Web design. Usually, the home page of an enterprise contains information about the company and the services it offers, as well as links to detailed information about the business. When online transactions are involved, a user is typically redirected to a Web page asking for user ID and password, thus enabling the user to log on to one or more applications. Typically, a Web page or section of a Web page is provided with an HTML form for a user to enter user ID and password and a button to submit the authentication data to the HTTP server. Providing the user ID and password will take the user to a page that is customized to that user and from where all the user account information can be securely accessed. For example, in our travel service scenario described on page 114, a user could log in and update credit information or view his or her travel itinerary , frequent flyer account details, and monthly billing statement.

Because basic authentication has virtually no customization capabilities and is also specific to a browser's characteristics, enterprise environments choose to use a login method whereby the user ID and password information are captured in an HTML form. This form-based login is not an option in the HTTP specification and is therefore specific to the application layer. Because this is a common enterprise scenario, this mode of authentication is standardized under the Java Servlet specification by allowing the value of the auth-method element in the login-config descriptor to be set to FORM .

The form-based login approach allows the WAS to use an HTML form to retrieve the user ID and password, as opposed to sending a 401 error code response as in the basic challenge type. When the value of auth-method is set to FORM , the user is redirected to the URL specified within the form-login-page element of the deployment descriptor. The form login page must contain the form elements j_username and j_password . The ACTION attribute associated with the form must be set to j_securitycheck . An example of such a login page is shown in Listing 4.5.

Listing 4.5. Sample Login Web Page for Form-Based Login

 <HTML>    <HEAD>       <TITLE>Fabrikam456 Login page</TITLE>    </HEAD>    <BODY BGCOLOR="#FFFFFF" TEXT="#000000">       <TR><TD><HR NOSHADE SIZE="1">       <FONT SIZE="-1" FACE="Helvetica,Arial" COLOR="#996600">       <B>Please log in!</B></FONT><BR><BR></TD></TR>       <CENTER>       <FONT SIZE=1 COLOR="Blue">       Enter your travel account name and password in order       to access our services       </FONT><BR>       <FORM METHOD=POST ACTION="j_security_check">       <FONT SIZE=1>Account       <INPUT TYPE=TEXT NAME="j_username" SIZE=20></FONT><BR>       <FONT SIZE=1>Password       <INPUT TYPE=PASSWORD NAME="j_password" SIZE=20>       </FONT><BR>       <INPUT TYPE=SUBMIT NAME=ACTION VALUE="Submit Login">       </FORM><HR>       </CENTER>    </BODY> </HTML> 

When the ACTION attribute associated with the form is set to j_securitycheck as in Listing 4.5, the WAS extracts the user ID and password from the form and validates them. The WAS recognizes the user ID and password because these are the values that the user entered in the j_username and j_password text boxes, respectively. If the authentication fails, the user is redirected to the Web page specified by the deployment descriptor's form-error-page element. An example of deployment descriptor login configuration using FORM as the authentication method is shown in Listing 4.6.

Listing 4.6. Sample Login Configuration for Form-Based Authentication

 <login-config> <auth-method>FORM</auth-method>    <form-login-config>       <form-login-page>/login.jsp</form-login-page>       <form-error-page>/login-failed.html</form-error-page>    </form-login-config> </login-config> 

Typically, the URLs specified in the form-login-page and the form-error-page are relative to the context path of the Web application to which the deployment descriptor refers. The context path of a Web application is the path prefix associated with the javax.servlet.ServletContext that the servlet or the JSP application is a part of. For example, let us consider again the URL http://www.fabrikam456.com:80/travel/reserve , which we used in the scenario described on page 000. A path prefix in a URL is a substring of the URL that excludes the protocol part, host name, and port number ( http://www.fabrikam456.com:80 ); it can either be a single forward slash ( / ) or start with a forward slash and end with the last character before a subsequent forward slash. For example, in the preceding URL, the possible path prefixes are / and /travel . Of these two path prefixes, the context path for the travel Web application is /travel . Therefore, the values /login.jsp and /login-failed.html are relative to /travel .

A typical HTTP communication flow with a form-based authentication request is summarized in Figure 4.5. A user who tries to access the secured resource, http://www.fabrikam456.com/travel/reserve , is redirected to the login Web page at http://www.fabrikam456.com/travel/login.jsp and presented with a login form. In the case of authentication failure, the user is redirected to the error page at http://www.fabrikam456.com/travel/login-failed.html . To protect the user ID and password during transmission, the entire HTTP transaction should be carried over the SSL protocol. ^[3] This implies that all the URLs in Figure 4.5 should start with https rather than http .

^[3] As we observed on page 116, when the credentials required of the user are user ID and password, it is not necessary for a server to require mutual-authentication SSL. The user ID and password transmission can be protected by using an SSL session with server-side authentication only.

Figure 4.5. Form-Based Login Request Flow Scenario

4.5.1.3 Certificate-Based Authentication Method

In public-key cryptography-based systems, the private key of a client stays with the client and is never sent over the network. The public key is available to the server, wrapped in a digital certificate (see Chapter 10 on page 372).

The SSL protocol is a public-key cryptography-based mechanism widely used in a Web environment. In particular, SSL is commonly adopted to achieve integrity and confidentiality of HTTP message transactions. As we discussed on page 96, when a Web server is configured to require mutal authentication with the end client over SSL, the client authenticates the server, using the server's digital certificate, and the server authenticates the client, using the client's digital certificate. These digital certificates are exhanged during the SSL handshake ”the phase in which the client and the server establish the SSL connection (see Section 13.1.2, on page 452).

Because a client's certificate is associated with a given principal on the client side of a mutual-authentication SSL connection, the client's certificate is considered a form of client authentication in a Web environment (see Figure 4.6). In such cases, successful negotiation of an SSL connection implies that the client certificate is signed by a CA trusted by the server and that the client who presented the certificate possesses the correct private key ”the one corresponding to the public key wrapped in the client certificate. It is also possible, and highly recommended, that a digital certificate be validated against a certificate revocation list (CRL) to ensure that it is still valid. The client-certificate contents can be used to derive the identity of the requester. This enables using client digital certificates to infer the identity of the clients and prove authenticity when performing authorization checks. The concepts of digital certificate, CA, and CRL are described in Section 10.3.4 on page 372.

Figure 4.6. Establishing a Principal's Identity Based on Mutual-Authentication SSL

In a J2EE environment, the authentication method for a Web application can be set to be certificate based by properly configuring the deployment descriptor in the Web application's Web module. In particular, the auth-method element in the login-config descriptor must be set to CLIENT-CERT , as shown in Listing 4.7.

Listing 4.7. Sample Login Configuration for Certificate-Based Authentication

 <login-config>    <auth-method>CLIENT-CERT</auth-method> </login-config> 

After the SSL handshake, the client's digital certificate can be made accessible to the WAS designated to handle the client's request. The WAS can then use the contents of the client's digital certificate to derive the identity of the requester. In particular, the WAS uses the client's digital certificate to represent a unique user, a group of users, or an organization. For example, the subject's name obtained from the client's digital certificate may be mapped to the short name of a user in an LDAP directory. Each certificate contains a field called the subject's Distinguished Name (DN). A subject's DN is a string representing the name of the entity whose public key the certificate identifies. The DN uniquely identifies the name of that subject across the Internet. According to the X.509 standard, a subject's DN contains the following attributes:

• Common Name (CN)

• Organizational Unit (OU)

• Organization (O)

• Location (L)

• State (ST)

• Country (C)

Let us consider the example of a subject whose DN is

 CN=Bob Smith, OU=Travel Division, O=Fabrikam456, L=Raleigh, ST=North Carolina, C=United States 

Because a subject's DN is unique, a direct match against the DN is the preferred way to obtain the corresponding user ID in the registry. If this option is not available, imperfect mappings can be used. For example, in the subject's DN, the CN attribute, Bob Smith , can be mapped to a user entry in an LDAP directory where the user's short name is bob . In this example, the policy to map the certificate is as simple as using the CN in the subject's DN to map directly to a user ID in the registry. Other attributes in the client certificate may be used to establish the user's identity. How a certificate-based authentication can be used to deduce the identity of the requester and details of mapping rules are outside the scope of the J2EE specification and depend on the J2EE product implementation.

Note that a J2EE WAS gets to handle a request after the SSL handshake is established at the transport layer, as shown in Figure 4.6. In many enterprise topologies, an SSL connection is established with a reverse proxy server that sits in a DMZ (see Section 6.2.2 on page 193). A reverse proxy server can accomplish several tasks , including content caching, load balancing, user authentication, and access-control enforcement. The machines that host the WASs are often different from the machine hosting the reverse proxy server. Therefore, it is common that the WAS designated to handle the client's request does not directly participate in the SSL handshake. Because the client's identity is derived from the client's digital certificate and is the basis for identifying the principal accessing the Web resource, the trust relationship between the WASs and the reverse proxy server acting as the server-side SSL end point must be properly designed. This may be achieved by establishing a mutual-authentication SSL connection between each WAS and the reverse proxy server.

4.5.2 Single Sign-On

As we discuss in Section 4.10.2 on page 149, the stateless nature of HTTP implies that every request a client submits is treated by a server as a new request. Therefore, if user authentication is required, a user will be asked to authenticate on every request. For example, if the authentication method is based on user ID and password, as in HTTP and form-based authentication, the user will be prompted to type and submit a user ID and password pair on every request. This scenario is annoying for the user and is considered user unfriendly. WASs offer a mechanism providing single sign-on (SSO), which means that users are prompted for their credentials only once. SSO can be achieved at various levels: browser, J2EE Web application, J2EE Web container, and others.

• HTTP realm. When HTTP basic authentication is used to retrieve user ID and password, a realm is specified as part of the challenge. When a user gets prompted for user ID and password for the first time in a browser session with an HTTP server, the browser typically caches the user ID and password information. When the user requests another secured resource from the same HTTP server and the HTTP server challenges the user for user ID and password under the same realm, the browser does not prompt the user again. Instead, it retrieves the information from its local cache and sends it back to the HTTP server. This is the least sophisticated level of SSO that is provided when using HTTP basic authentication as implemented by Web browsers.

• HTTP state management mechanisms. If a user is authenticated with user ID and password using form-based login, the browser-supported SSO is not feasible . The J2EE specification formalizes the notion of SSO over multiple HTTP requests and requires J2EE products to provide some form of SSO so that users will be prompted only once for all authentication requests that target the same WAS. In order to satisfy this requirement with form-based authentication, WASs maintain the user authentication information across multiple requests using HTTP state-management mechanisms, such as HTTP cookies (see Section 4.10.2.1 on page 150), HTTP sessions (see Section 4.10.2.2 on page 151), or SSL sessions.

• SSL session. In the case of certificate-based authentication, an SSL connection is maintained across multiple HTTPS requests. Therefore, the client's certificate information is available on every request without the user's being prompted multiple times. SSO in these scenarios comes for free because all the HTTP requests are carried over a single SSL session.

  It must be noted, however, that this option is not always available. As observed in Section 4.10.2.2 on page 151, some Web servers are configured to renegotiate the SSL session with the client from time to time. This results in a change of the session ID and hence the loss of session information.

An e-business scenario may involve multiple organizations participating in the same transaction. For example, a user contacting a real estate agency on the Internet may be temporarily redirected to an associated home mortgage organization. After having been preapproved for a mortgage, the user is then readmitted to the real estate agency's Web site. The real estate agency's WAS can now personalize the response sent back to the client by showing the user only those houses that the user can afford, based on the mortgage amount calculated by the home mortgage organization. A scenario like this involves multiple HTTP servers, each belonging to a different Domain Name Service (DNS) system. In such scenarios, if various organizations require client authentication, none of the previous solutions would achieve SSO, for the following reasons.

• Browser-supported SSO for HTTP basic authentication is not applicable , because the organizations requiring client authentication belong to different DNS systems and therefore fall within different HTTP security realms.

• Cookie-based SSO in form-based authentication would not work, because HTTP cookies are valid for hosts that fall within a specified DNS system. A securely configured Web browser would refuse to allow an organization's HTTP server to retrieve the cookie set by another organization's HTTP server if the two servers belong to different DNS systems.

• Finally, it should be noted that an SSL session between a client and a server cannot be transferred from one server to another. The second server should engage in a new SSL handshake with the client. Therefore, the SSO intrinsically supported by certificate-based authentication cannot be used when an enterprise spans multiple organizations, each having its own HTTP server belonging to a different DNS system.

In such cases, sophisticated enterprise SSO solutions are typically deployed. These solutions are outside the scope of the J2EE specification and depend on the implementation of the J2EE product and other external security products that can work with the J2EE product.