User Authentication Schemes
The process of authenticating users, or client programs running on behalf of the user, for Web applications is different from the one specified by JAAS (Java Authentication and Authorization Service) that we went over in the Access Control chapter. The main difference is that a Web application runs within the context of a Web container and is accessed by a user through a Web browser, over HTTP, whereas JAAS is designed for scenarios where the user-facing component and the backend component are both Java programs running within the same JVM. JAAS doesn't have to worry about secure exchange of sensitive username and password information between two programs, possibly over an insecure network.[2] An insecure network could allow the data to be read and/or altered by a malicious third party. These are the kinds of issues an authentication mechanism for Web applications must address.
[2] It is possible to use JAAS for distributed programs where the authenticated subject is transmitted from one program to another, provided both are Java programs and the security of the exchange is guaranteed through other means.
HTTP/1.1 specification defines two authentication schemes for authenticating a client to a server: Basic Authentication Scheme and Digest Authentication Scheme. Besides these schemes, a Web application can authenticate a user by prompting the user for a username and password by sending an HTML FORM to the browser, getting this information within a HTTP POST request and passing it to a user account system for validation, very much the same way as is done by JAAS. This scheme is also known as FORM-based Authentication Scheme, due to its reliance on the HTML FORM element. A fourth authentication scheme is possible when the underlying transport for HTTP is SSL. Recall that SSL can optionally require the client to present its own X.509 certificate and prove possession of the corresponding private key. This scheme is known as Certificate-based Authentication Scheme.
A J2EE Web container is required to support all but the HTTP Digest authentication schemes. We cover the specifics of this support in the next section. The focus of this section is to learn about these mechanisms independent of what setup is needed in a Web container to make them work.
Basic Authentication Scheme
This scheme works in three steps, using a technique known as a challenge-response mechanism:
1. | The client requests the server for a resource, with the request URI included in the HTTP request identifying the resource. |
2. | The server responds that access to this resource is limited to authenticated users and challenges the client to provide client credentials (i.e., username and password information). |
3. | The client repeats the request, including the username and password information as part of the request. |
The request succeeds if the server is able to validate the supplied user credentials. Otherwise, the server resends the challenge response.
The relevant portions of a successful exchange between a client and server using Basic Authentication scheme is shown below:
[1]C --> S GET /rmb2/index.jsp HTTP/1.1 ... skipped ... [2]C <-- S HTTP/1.1 401 Unauthorized ... HTTP headers skipped ... WWW-Authenticate: Basic realm="RMB2 Basic Authentication Area" ... skipped ... [3]C --> S GET /rmb2/index.jsp HTTP/1.1 ... HTTP headers skipped ... Authorization: Basic cGFua2FqOnBhbmthag== ... skipped ...
Essentially, the server challenge is an HTTP header WWW-Authenticate whose value consists of the authentication scheme identification ("Basic") and a realm string ("RMB2 Basic Authentication Area"). The realm value is an opaque string assigned by the server to partition its URI space into multiple protection spaces, each having its own unique realm value.
The client response is also an HTTP header. This header is named Authorization and its value consists of the authentication scheme identification ("Basic") and base64 encoded value of "username:password" string ("cGFua2FqOnBhbmthag=="). Subsequent requests for resources in the same protection space use the same Authorization header.
Although the user credentials portion of Authorization field appears to be inscrutable at first sight, it can easily be converted back to the original string having the username and password in clear-text by base64 decoding. This makes Basic authentication a rather weak mechanism as anyone who can snoop on the network can collect the username and password. The problem is made worse by the fact that people usually keep the same username and passwords for multiple accounts and a weak authentication mechanism of one account could lead to compromise of other accounts as well.
Recall the authentication process of the Tomcat Manager and the browser-generated login panel. That process was done using HTTP Basic authentication. The browser caches the username and password information and uses this value for all request URIs with the same realm string.
Digest Authentication Scheme
The Digest Authentication scheme is also based on a challenge-response mechanism and the pattern of exchange between a client and server is somewhat similar to that of Basic Authentication. The main difference is the fact that the password is never transmitted over the wire in a form that can be used by a snooper to recover it. This property makes Digest Authentication much more secure than Basic Authentication. However, it is not widely deployed and, in fact, is not even required to be supported by J2EE-compliant systems. Still, it is instructive to learn how it avoids transmission of the password in clear-text.
How is Digest Authentication able to avoid transmission of the password over the wire? The answer is apparent from a look at this sample exchange:
[1] C --> S GET /rmb2/index.jsp HTTP/1.1 ... skipped ... [2] C <-- S HTTP/1.1 401 Unauthorized ... HTTP headers skipped ... WWW-Authenticate: Digest realm="RMB2 Digest Authentication Area", qop="auth", nonce="f9b9c89377323747f5b3825093f31a0b", opaque="ac052870edb30301762b7e860ef75deb" ... skipped ... [3] C --> S GET /rmb2/index.jsp HTTP/1.1 ... HTTP headers skipped ... Authorization: Digest username="pankaj", realm="RMB2 Digest Authentication Area", qop="auth", algorithm="MD5", uri="/rmb2/index.jsp", nonce="f9b9c89377323747f5b3825093f31a0b", nc=00000001, cnonce="b0f1d2743b114410b19beea2dd8778e0", opaque="ac052870edb30301762b7e860ef75deb", response="7956e10c4fa50167f9a7a562dbbbfbed" ... skipped ...
Line breaks have been added in the value of HTTP headers WWW-Authenticate and Authorization for readability and are indicated by character ''. A real exchange will not have this character and the line breaks.
Without getting into details of the fields used in the challenge header WWW-Authenticate and response header Authorization, we note that the challenge includes a nonce value, something that changes with time, and the response is a one-way hash (using MD5 algorithm) of the username, the password, the given nonce value, the HTTP method and requested URI. On receiving a request with such an Authorization header, the server computes the one-way hash using the password stored in its user account system and matches it with the hash value of the request for validation.
As you can see, this mechanism avoids transmission of the password in clear-text.
The realm attribute has the same meaning as in Basic Authentication and is used to partition the URI space into multiple authentication zones. In fact, the browser treats Digest Authentication in a manner similar to Basic Authentication in many other ways also. These include prompting the user with the browser generated login panel and caching of the username and password for the life of the browser execution.
The use of the request URI and nonce value in computing the hash provides protection against replay attacks. A server would be able to detect if a third party captures the request and tries to issue the captured request at a later point in time or for another request URI.
FORM-Based Authentication Scheme
As we mentioned earlier, in a FORM-based authentication scheme, username and password are transmitted in clear text, as part of the HTTP POST request body. This makes it vulnerable to the same snooping attacks as the Basic Authentication. However, if snooping could be avoided by some other means, say by encrypting the transmitted data, as is the case when HTTP traffic flows over SSL, then this mechanism is quite safe.
In fact, FORM-based authentication over SSL is quite popular for a number of reasons:
The application can control the look and feel of the login window.
The error message, on unsuccessful login, can be customized to display a friendly message.
The application has more control over “logged in” status of the user, allowing a user to logout once the security sensitive operation is over.
The Tomcat Administration Tool uses FORM-based authentication.
Certificate-Based Authentication Scheme
Certificate-based authentication requires configuration of the server to accept HTTP requests over SSL and demand client certification during an SSL handshake. When the client is a browser, then the browser looks for a conforming X.509 certificate and private key in its certificate store. Note that these certificates are not the same ones that come bundled with the browser and are used to validate the server certificates. Only a certificate issued to an entity that possesses the corresponding private key can be used for client authentication.
The browser may prompt the user to confirm a particular certificate or to select one from multiple conforming certificates. As the certificates with the private keys are typically password protected, the user will have to supply the certificate password as well.
This scheme is the strongest of all the authentication schemes discussed here but is rarely used in Web applications, due to the complexity involved in obtaining and managing personal certificates.