IBM Support

inactive-timeout/timeout delay in webseald.conf will have some delay before taking effect



The inactive-timeout/timeout will not always take effect EXACTLY at the time specified in webseald.conf.. For example, if you have the following settings.. [session] timeout=43200 inactive-timeout=3600 (60 min.) You will notice that re-authentication due to inactivity will occur somewhere around 60 - 75 min. of inactivity. (with a delay of couple of min. from what has been set in the inactivie-timeout parameter)


The session timeout mechanism is a separate thread that checks for inactivity and total durations against every session in WebSEAL's cache.

Because the operations involved are relatively expensive and WebSEAL may have many sessions to check, the session timeout thread does not make continuous, or even frequent checks against the session cache.

The thread sleeps for 1/4 of either inactive-timeout or timeout, whichever is shorter. When its done sleeping, it runs through every session to flag the expired ones, then goes back to sleep.

So if a user begins his session shortly after a period during which the session timeout thread made its last check, his session will not timeout until after the next four checks are made. It appears inconsistent because testers have no way of knowing where in the session timeout thread's sleep/check cycle they have initiated their session lifetime. Furthermore, they don't know how long it has been since the session has actually expired.

 ^a ^b                  ^c

A monospace font will display the above diagram correctly.
1) A session is initiated, and further activity ceases.
2) The session timeout thread notes the beginning of the session's inactivity.
3) The fourth timeout check after inactivity began arrives, and the timeout
   thread flags the session. A grace period preserves the session temporarily,
   should the user re-authenticate.
4) The user makes another request and discovers his session has expired.

The letters a, b, and c signify points on a timeline. Each vertical bar represents the point where the thread checks for inactive-timeout. You will observe c - a can be significantly larger than c - b, the inactive-timeout.


Resolving The Problem

The delay for inactive-timeout/timeout is working as designed.

From below patches, you can use max-timeout-flush-interval in [session] stanza (in sec.) to set flush interval:

4.1 LA18

5.1 LA14

6.0 FP03

6.1 GA and later versions

Please note that this document is applicable for all versions including ISAM 7 and 8 as of 2015/Feb/16.

[{"Product":{"code":"SSPREK","label":"Tivoli Access Manager for e-business"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"WebSEAL","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All versions","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
16 June 2018