SRV.11.5 Authentication | Java 2 Platform, Enterprise Edition: Platform and Component Specifications

A web client can authenticate a user to a web server using one of the following mechanisms:

HTTP basic authentication
HTTP digest authentication
HTTPS client authentication
Form based authentication

SRV.11.5.1 HTTP Basic Authentication

HTTP basic authentication is the authentication mechanism defined in the HTTP/1.1 specification. This mechanism is based on a username and password. A web server requests a web client to authenticate the user. As part of the request, the web server passes the string called the realm of the request in which the user is to be authenticated. It is important to note that the realm string of the basic authentication mechanism does not have to reflect any particular security policy domain (which, confusingly, can also be referred to as a realm). The web client obtains the username and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm.

Basic authentication is not a secure authentication protocol as the user password is transmitted with a simple base64 encoding and the target server is not authenticated. However, additional protection, such as applying a secure transport mechanism (HTTPS) or using security at the network level (such as the IPSEC protocol or VPN strategies), can alleviate some of these concerns.

SRV.11.5.2 HTTP Digest Authentication

Like HTTP basic authentication, HTTP digest authentication authenticates a user based on a username and a password. However the authentication is performed by transmitting the password in an encrypted form which is much more secure than the simple base64 encoding used by basic authentication. This authentication method is not as secure as any private key scheme such as HTTPS client authentication. As digest authentication is not currently in widespread use, servlet containers are not required, but are encouraged, to support it.

SRV.11.5.3 Form Based Authentication

The look and feel of the "login screen" cannot be controlled with an HTTP browser's built-in authentication mechanisms. Therefore this specification defines a form based authentication mechanism which allows a developer to control the look and feel of the login screens.

The web application deployment descriptor contains entries for a login form and error page to be used with this mechanism. The login form must contain fields for the user to specify username and password. These fields must be named 'j_username' and 'j_password' , respectively.

When a user attempts to access a protected web resource, the container checks if the user has been authenticated. If so, and dependent on the user's authority to access the resource, the requested web resource is activated and returned. If the user is not authenticated, all of the following steps occur:

The login form associated with the security constraint is returned to the client. The URL path which triggered the authentication is stored by the container.
The client fills out the form, including the username and password fields.
The form is posted back to the server.
The container processes the form to authenticate the user. If authentication fails, the error page is returned.
The authenticated principal is checked to see if it is in an authorized role for accessing the original web request.
The client is redirected to the original resource using the original stored URL path.

If the user is not successfully authenticated, the error page is returned to the client. It is recommended that the error page contains information that allows the user to determine that the authorization failed.

Like basic authentication, this is not a secure authentication protocol as the user password is transmitted as plain text and the target server is not authenticated. However, additional protection, such as applying a secure transport mechanism (HTTPS) or using security at the network level (IPSEC or VPN), can alleviate some of these concerns.

SRV.11.5.3.1 Login Form Notes

Form based login and URL based session tracking can be problematic to implement. It is strongly recommended that form based login be used only when the session is being maintained by cookies or by SSL session information.

In order for the authentication to proceed appropriately, the action of the login form must always be " j_security_check ." This restriction is made so that the login form will always work no matter what the resource is that requests it and avoids requiring that the server process the outbound form to correct the action field.

Here is an HTML sample showing how the form should be coded into the HTML page:

 <form method="POST" action="j_security_check">  <input type="text" name="j_username">  <input type="password" name="j_password">  </form>

SRV.11.5.4 HTTPS Client Authentication

End user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism. This mechanism requires the user to possess a public key certificate (PKC). Currently, PKCs are useful in e-commerce applications and also for single-signon from within the browser in an enterprise. Servlet containers that are not J2EE compliant are not required to support the HTTPS protocol.