Agent Guide › Session Handling › Timeout Handling

Timeout Handling

In the case of idle timeouts, the SiteMinder idle timeouts for every realm must be set greater than or equal to the WebSphere LTPAToken timeout. This is because if the SiteMinder idle timeout is less than the LTPAToken, then users moving from WebSphere to SiteMinder will be: Challenged for credentials if they enter WebSphere for the first time after the idle timeout; after that, the TAI is not invoked and the JACC denies all request with a 403 error.

In the case where the SiteMinder idle timeout is greater than the LTPAToken timeout, the SiteMinder session ticket will be valid even though the LTPAToken has timed out. This would result in the existing SiteMinder session ticket being propagated back to SiteMinder and eventually this would result in skews between SiteMinder and WebSphere timeouts. In this case, WebSphere will force a rechallenge and the TAI will create a new SiteMinder Principal with refreshed last access times.

In the case of SiteMinder maximum timeouts, the maximum timeout must be a multiple of idle timeout. For example, if idle_timeout = LTPA_cookie_timeout = 1 hour, then max_timeout must be (n * idle_timeout) where n = 1, 2, 3, 4, and so on. This forces WebSphere to trigger the TAI again to challenge the user for updated credentials.

Note: Max timeout settings can result in timeout skew; if the timeouts are not synchronized and a user session hits the maximum timeout, the user must close the browser session and open a new one.