Servlet Container Authentication

There are three required authentication mechanisms supported by a compliant Servlet Container: HTTP Basic Authentication, Form-based Authentication, and CLIENT_CERT authentication. There is a fourth authentication method, DIGEST, that isn’t used very often in my experience. This final authentication method is very similar Basic Authentication except that the password is encrypted. In this discussion, an assumption is made that all requests will occur over SSL and that transport layer encryption will address confidentiality concerns.

For the moment, the Authorization step is going to be treated as an abstract that is always successful.

HTTP Client – Basic Authentication


Figure 2 — HTTP Client with Basic Authentication

The HTTP Client doesn’t have to necessarily be a web browser. It could be any HTTP-compliant client; this could be any number of software programs. This scenario is rather generic. No details of the authentication and authorization steps are given. Note, we will refer to web browsers, software programs making HTTP calls, and anything else making an HTTP call as an HTTP Client.

Basic Authentication for the HTTP 1.1 spec is defined in RFC 2617. For completeness, RFC 2616 defines HTTP 1.1.

Listing 3 below describes the sequence of events involved in Basic Authentication. A browser makes an HTTP GET request for index.html. The server sees that the requested page is protected and that Basic Authentication should be used. The server looks for credentials in the request, but won’t find any. So, a “401 Challenge Response” will be returned; this HTTP Response includes a WWW-Authenticate HTTP Header, which tells the browser that it must prompt the user for credentials (a username and password). The user enters these credentials. The browser resends the original HTTP GET request for index.html to the server, but this time an AUTHORIZATION Header with username and password is included. Upon receipt of the new request with the security credentials, the server once again checks for the AUTHORIZATION Header, finds it, extracts the credentials, attempts to validate those credentials against a User Repository, and if successfully, allow the request to be fulfilled. Assuming successful authentication of the user’s credentials, the index.html page will returned with an HTTP 200 OK response.

Do not let the name of the HTTP AUTHORIZATION Header be confusing; despite the name, it contains security credential information used during the Authentication step. The HTTP AUTHORIZATION Header contains a username and password that are base-64 encoded. The format of the value is “username:password”. If the credentials to be given to the server were “bob:password”, the AUTHORIZATION Header’s value would be “Ym9iOnBhc3N3b3JkCg==”. If you ever need to determine what a submitted userid and password from a HTTP Request dump are, the following command can be used to decode the value:

$ echo “Ym9iOnBhc3N3b3JkCg==” | base64 -d


So, the encoded value in the previous paragraph contained “bob:password”, which means the username was “bob” and the password was “password”. Ideally, passwords used in the wild would be harder to guess.

Notice, that base64 encoding is not encryption. It obfuscates the security credentials, but it does not truly protect them from unauthorized access. So, SSL must be used to encrypt the communication between browser and server.

It is often noted that Basic Authentication is not secure. Basic Authentication over unencrypted channels is generally not secure, but its use in conjunction with SSL is sufficient for many situations.


Figure 3 — HTTP Basic Authentication Sequence

Other Forms of Authentication

The other forms of authentication mentioned above will be described in later articles.