Tuesday, July 06, 2004

Authentication Web Components

Once the database components have been installed, the web components may be implemented. The web components needed for authentication include a login page and a controller. The login page has four form elements:

  1. a text field (username)
  2. a password field (password)
  3. a hidden field (target)
  4. a submit button (Login)

When the Login button is pressed, the form is submitted to the controller.

The controller processes all login and logout requests. After processing, the controller issues an HTTP 302 redirect or forwards the request to another component (e.g., the login page). The controller does not return HTML (or other markup).

The controller supports two actions: login and logout. The corresponding URLs are:


The default action is the login action. A GET request for the login action results in the login page. A POST request for the login action includes two additional parameters: username and password. A POST request for the login action always results in a redirect.

A POST request for the login action causes the following steps to occur (in order):

  1. authenticate the user
  2. update the sessions table
  3. create the cookie
  4. redirect the client

Each step depends on the success of the previous step.

To authenticate the user, the controller hashes the password and queries the users table:

SELECT username FROM users
  WHERE username = 'username'
  AND password = 'hashedPswd';

The username and hashedPswd are the input username and the MD5 hash of the input password (resp.). The login action proceeds to the next step if the SELECT returns a result.

Next the controller creates and stores an unique session ID:

  ( 'sid', 'username' );

These two steps constitute a database transaction, which must be executed atomically. A better approach is to write a database stored procedure:

stored_proc( 'username', 'hashedPswd' ) ==> 'sid'

The stored procedure authenticates and creates a session in one step.

If the login action succeeds, a cookie is created on the client:

Set-Cookie: SID=sid; path=/; domain=.my.com; secure

This creates a secure cookie visible throughout the my.com domain. The cookie persists for the life of the browser (max).

If authentication is unsuccessful, the controller redirects to the login page. If the authentication is successful and the request has a parameter called target, the controller redirects the client to the target URL. If there is no target parameter, the user is redirected to a personalized portal page.

A request for the logout action always results in a redirect. A GET logout request is equivalent to a POST logout request. In either case, the session ID is invalidated in the sessions table:

DELETE FROM sessions WHERE sid = 'sid';

Instead of physically deleting the session, it may be marked for deletion in the sessions table (with associated cleanup issues).

To complete the logout action, the cookie is expired on the client:

Set-Cookie: SID=; path=/; domain=.my.com; secure; 
  expires=Thursday, 01-Jan-70 00:00:00 GMT

This is a relatively minor issue however, since the corresponding entry in the sessions table has been invalidated. Any subsequent validation attempt will fail.

The target parameter allows seemless integration of the authentication framework. The value of the (optional) target parameter is an absolute URL. The controller redirects to the target URL after completing the action. The default login target is a portal page. The default logout target is the login page.