Sharing sessions across multiple DNS domains

When operating in a multi-domain environment, we must use a different mechanism to communicate the session identifier to the WebSEAL servers in the different DNS domains.

The index into the distributed session cache is stored and transmitted in a domain cookie. Clients do not present this cookie to servers that reside outside of the source DNS domain. Extensions to the external authentication interface (EAI) allow an EAI application to supply WebSEAL with a session identifier instead of authentication data. For more details, see External authentication interface HTTP header reference. This session identifier corresponds to the session index into the distributed session cache. The mechanism by which the EAI application receives the session identifier depends on the implementation of the EAI application. For example, we can configure:

For this mechanism to work, designate a single WebSEAL server or multiple load-balanced Web servers in the same DNS domain as the primary authentication server. This WebSEAL server establishes the authenticated session. It also hosts the identity provider, which communicates the session identifier back to the EAI application.

To make the session identifier available to the identity provider application, see User session management for back-end servers.

The following diagram shows the basic process flow for session management in a multi-domain environment where WebSEAL is configured to use the distributed session cache. The example is based on the following conditions:

Steps

  1. A user makes a request for a protected object located in the Web space of WebSEAL B, which:

    • Intercepts the request.

    • Creates a local cache entry for the user.
    • Sends a redirect back to the identity provider application that is behind the primary authentication server. We can either set this redirect as a meta-header within the login form or specify it using the local-response-redirect functionality.

  2. The identity provider is a protected application that requires authentication. WebSEAL A:

    • Intercepts the request.

    • Creates a local cache entry for the user containing the requested URL for the identity provider.
    • Prompts the user to log in.

  3. The user provides authentication data to WebSEAL, which performs a local authentication and updates the local session cache entry with the credential of the client.

  4. WebSEAL A notifies the distributed session cache of the new session and the associated credential information. The distributed session cache maintains this information in its database.

  5. WebSEAL A sends:

    • A session cookie to the browser of the user.
    • A redirect to the cached URL for the identity provider.

  6. The identity provider:

    • Extracts the session identifier from the HTTP request headers.
    • Sends a redirect to the EAI application junctioned behind WebSEAL B. The mechanism for passing the session identifier to the EAI application is implementation-specific.

  7. The EAI application:

    • Locates the session identifier supplied by the identity provider.
    • Passes the identifier back to WebSEAL B in the appropriate HTTP header.

  8. WebSEAL B retrieves the corresponding session from the distributed session cache.

  9. WebSEAL B sends:

    • A session cookie to the browser of the user.
    • A redirect to the original cached URL.

  10. WebSEAL B:

    • Uses the session cookie set in step 9 to locate the appropriate local session and credential.
    • Allows the request for the resource to proceed.
    • Does not prompt the user to log in again.

Parent topic: Distributed session cache overview