Controlling the login_success response

In a network topology involving multiple WebSEAL instances controlled by a load balancing system, the request URL can be "lost" during the communication exchange that occurs for the authentication process. For example, it is possible for one WebSEAL instance to receive the request URL (for a protected resource) and present the user with a login form. When the user submits the completed login form, a non-sticky load balancer might send the POST data to a second WebSEAL instance. (Sticky load balancing is the distribution of user requests across a set of servers in such a way that requests from a given user are consistently sent to the same server.)

This second WebSEAL instance can successfully process the login POST data, but is not able to redirect to the original URL request. In this case, the second WebSEAL instance sends the login_success.html page that reports the message "Your login was successful." WebSeal does not make use of the Referer header, because if the initial unauthenticated request was a POST, a redirect to the original URI would result in a GET to a resource which should receive a POST.

There are several possible solutions:

See Automatic redirection after authentication for complete information.

  • Modify the login_success.html response page so that it redirects the user's browser back in the request history. This technique allows the second WebSEAL instance to receive and process the original request URL. For example:

      <HTML>
      <HEAD>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <TITLE>Success</TITLE>
      </HEAD>
      <BODY onLoad="history.back()">
      ...
      </BODY>
      </HTML>

    Parent topic: Load balancing environments