Tuesday, July 06, 2004

Authentication Web Service Components

Assume the database components and web components for authentication/SSO are already in place. The next step is to integrate an application into the authentication/SSO framework.

Any given application must validate the session ID stored in the client-side cookie. Validation occurs at the time a protected resource is requested. Rather than install elaborate validation components in the application itself, we describe a validation web service that accepts validation requests via HTTP. To make use of the web service, an application need only do two things: 1) make an HTTP request, and 2) parse an XML document. These modest requirements make it relatively easy to integrate an application into the authentication/SSO framework.

The web service and the authentication controller share the same database (but are otherwise separate). When the web service receives a validation request, it checks to see if the given session ID is in the database. Validation succeeds if and only if the session ID is in the database. Subsequently an XML document is returned to the client application. The XML document encodes the validation response.

The web service relies on an XML template. This template is used to formulate a validation response. The XML DTD may be of ad hoc design or standard design (e.g., SAML).

The web service supports one action: validate. The corresponding URL is:


A request for the validate action always results in an XML document. Both parameters (action and SID) are required. For enhanced security, a request for the validate action should be a POST request with SID parameter encoded in the body of the request.

When requested, a protected resource performs the following steps:

  1. Extract the cookie (SID) from the request
  2. If the cookie does not exist, redirect the client to the login page with parameter target=self
  3. If the cookie does exist, request the web service with SID as parameter
  4. If the parsed XML indicates failure, redirect the client to the login page
  5. If the parsed XML indicates success and the user possesses the desired role, return the requested resource to the client

When requested, the web service performs the following operations. If the session ID is in the sessions table, the request is valid:

SELECT username FROM sessions
  WHERE SID = 'sid';

Since the SID is the primary key of the sessions table, this query will return 0 or 1 results. If the request is valid, the web service determines the corresponding roles:

SELECT role FROM roles
  WHERE username = 'username';

The resulting roles are encoded in the XML and returned in the response along with the username.

It is up to the client application whether to enforce access restrictions. If the desired role is contained in the list of roles returned from the web service, access is allowed. Other approaches to access control (discussed later) remove this decision-making process from the application.