Session Timeout in Oracle Access Manager

Session Timeout in Oracle Access Manager (OAM)

The session lifetime and Idle timeout entries control how long a user's session is valid. In OAM, a user session is an object which represents an authenticated user. This object is stored in the server memory and if Database session persistence is enabled, this object is stored or available in the database. Each session is unique and is identified by both a userid and Session ID (session identifier), see screenshot below "OAM User Session Management". A valid session means a user has been authenticated with OAM. A session can have following three states:
1) active
2) inactive
3) expired
When a session is created it is in active state and is available as an object in the OAM. After a set time - idle timeout, the session moves or transitions to inactive state. And finally after the Session Lifetime time, the session is marked as expired. Expired sessions are removed from server memory. Read more about Session Lifetime cycle at the end of this post.

Session timeout is especially important when your single sign-on has been configured for a user session. Once user has authenticated to Oracle Access Manager (OAM) and sso has been enabled, the user need not re-authenticate to the Application. However if the user session remains idle- meaning user has not accessed any of the application then user will be challenged to re-authenticate upon expiry of the Idle time.

Note: Closing or exiting the browser will end the session of the user irrespective of the session timeout.

Since OAM 11gR2, if DCC (Detached Credential Collector) has been enabled, then take care to set the value of Token validity for each of the webgate settings. See the second screen below.

Update: Maximum Session Timeout at  Application domain level is not supported as per Oracle support 


Session Lifetime can be configured for OAM in the common settings as shown below. The default values are 480 minutes for session lifetime and 15 minutes for Idle timeout (as shown in the screenshot below). The maximum number of sessions indicates the allowed concurrent active connections. If any more concurrent connections are attempted they will get an OAM error message instead of the requested resource indicating the max number of sessions has been exceeded, contact your administrator. The session lifetime is a global setting and will take precedence to expire the session lifetime. Once Idle timeout value is reached the session has to be re-authenticated.
Note: Setting value of 0 is special case for both session lifetime and idle timeout which disables the value. Only use this for any specific requirement or during testing..

Check this link for details  Link  Maintaining Access Manager Sessions 11gR2 11.1.2.2 on https://docs.oracle.com/cd/E40329_01/admin.1112/e27239/session_R2.htm#AIAAG87654

For latest reference to OAM 12c Session Lifetime refer here

Description of "Figure 15-2 Session Details: Common Settings Page" (from Oracle doc 11gR)

The above settings are from OAM 11gR2 however the settings remain same in the latest OAM 12c, check here.

Table 15-1 (below) describes common session life cycle settings and their defaults. Sessions can operate in a disconnected mode (mod_osso, for example). Therefore, changes to the configuration establishing your session rules apply only to new sessions. If you need changes to apply immediately, Oracle recommends that you terminate existing sessions and force users to create new ones that adhere to your new rules.

Table 15-1 Common Session Settings

Setting	Description
Session Lifetime (minutes)	The amount of time, in minutes, that a user's authentication session remains active. When the lifetime is reached, the session expires. Default = 1440 minutes (24 hours specified in an integer representing minutes) A value of zero (0) disables this setting. Any value between 0 (zero) and 2147483647 is allowed. Note: An expired session is automatically deleted from the in-memory caches (or database).
Idle Timeout (minutes)	The amount of time, in minutes, that a user's authentication session remains active without accessing any Access Manager protected resources. When the user is idle for a longer period, they are asked to re-authenticate. Default = 15 minutes A value of zero (0) disables this setting. Any value between 0 (zero) and 2147483647 is allowed. Session data for an inactive session is automatically deleted from the in-memory caches (or database). Note: Session data for an inactive session is automatically deleted from the in-memory caches (or database) when a session's idle timeout is passed. OAM Server recognizes the idle timeout and restarts authentication using the same session.

Maximum Number of Sessions per User

The exact number of sessions each user can have at one time. Use this setting to configure multiple session restrictions for all users. Any positive integer is allowed. Specifying the count as "1", activates a special mode. If a user who already has a session authenticates using another device (thereby creating a new session), then their existing session is deleted. No error is reported and no warning is given. Note: Too high a number impacts performance and result in a security risk. Oracle recommends less than 20 as a reasonable limit per user. Otherwise there can be performance impact. For tuning information, see Oracle Fusion Middleware Performance and Tuning Guide.

Database Persistence for Active Sessions Enabled

Persists active sessions to the configured database session store, in addition to the local and distributed caches. Sessions are retained even if all managed servers die off. Default = Enabled (checked) If this is overkill for your environment, or you want to perform deployment sizing to take into account the database, you can clear the checkbox and restart all OAM Servers to disable this function.

Check the Token Validity Period is in seconds (see below screen, the Token Validity Period is on the left hand side middle). If the deployment is of DCC then ensure that you have set Token Validity time to be less than application specific time out. If your deployment has multiple webgates then you have to configure the Token validity period in each of the webgate.

WebGate configuration settings

The above screen is for each webgate. i.e. if you have multiple webgates, then you need to review each of the settings in the above screen. If any of the settings, like Token Validity period are changed, then you require to do a OAM restart and also OHS (Oracle HTTP Server) service, where webgate is installed (typically webgate is installed on a web server like OHS, Apache and for windows IIS server).

Quick note about a user's Session Management in OAM. Internally OAM creates a unique sessionid for each user session. This unique sessionid helps OAM keep track of each of the user session. Here is a screenshot of the OAM User Session Management. You can see it provides a full table

OAM User Session Management

of current user sessions in OAM with the fields - Session ID, Creation Instant, Last Access Time, Client IP Address etc. The Client IP Address provides the IP from where the user has initiated the session. "Creation Instant" provides the time when the user first authenticated to OAM/Application and Last Access Time is the most recent access to the Application. This screen is like a real-time user activity console where you can see all the current sessions via the OAM. Please note: Expired sessions are removed from this table (at the backend this is the database table that holds the information about the sessions), so you can consider the entries in this table to be ephemeral. You can even search in this screen via the User ID to see only those user sessions of your interest.

Maximum number of sessions per user: Use this setting to control how many sessions can one user initiate with the OAM/applications. For example if a user logs onto an application from his desktop (this will be counted as his first session), and may also access the same application from his mobile device (this will be counted as the second session), then one can set this number to 2 or 3. It is a good idea to configure this number of current sessions to a minimum as required, per your environment/number of applications that OAM is protecting. This setting for "Maximum number of sessions per user" tracks the number of concurrent session a user has initiated with the OAM/protected applications. Set this number of allowed maximum number of sessions per user depending upon the number of applications your OAM is protecting. For example, if the same OAM server is configured to protect, say 3 applications- OBIEE, WebCenter Portal, Oracle BAM and your typical user has been granted access to these applications, then you definitely need to set this max number of sessions above 4. It is ok to set this to 8 (which is default value). You can track each of the user sessions via the OAM console. Each session is allocated a unique session id so it can be tracked. Keep in mind if the max number of session is set to, say for example 8, and if the user already has 8 current sessions established, then any additional session initiated by the user, i.e. user attempting a new session with an application protected by OAM will be denied. User will get the OAM splash screen -denying the access. See the OAM splash screen message below- The user has already reached the maximum allowed number of sessions. Please close one of the existing sessions before trying to login again.

Note: The Max count number as "1" is a special case. 

Specifying the Max count as "1", activates a special mode wherein, if a user who already has a session authenticates using another device (thereby creating a new session), then their existing session is deleted. No error is reported and no warning is given. So use this setting (of Max number of sessions as "1") only when required. FYI, do not set this value as "1".

How OAM differentiates between various User session state

OAM differentiates between various session states based on the table below. The table below describes the criteria OAM uses to check what is the state of a session- whether the session is still active, or is the session still in its idle state, and finally if the session has expired. An expired session is deleted from OAM's in memory cache (and database). Here are there scenarios - (a) Say a user tries to access a protected URL, OAM will determine if the user is currently already authenticated and session is still active, if Yes then OAM allows user the access. (b) However, if OAM determines that a user session in its idle state (based on the Idle timeout setting), then user has to re-authenticate again, but all the session parameters remain same, i.e. already available session state of this user are preserved, and user is granted access upon re-authentication. And finally (c), if user attempts to access a protected URL, and OAM determines that the user session has expired (based on "Session Lifetime"), then not only user has to, of course, re-authenticate, but internally OAM creates a brand new session for this user. See the table below.

Table: Session check for Stage changes

Session Check	Description
Is the Session Idle?	Compares the last access time against the configured Idle Timeout value. Exceeding the configured period triggers a change from the Active to the Idle state.
Is the Session Expired?	Compares the session creation time against the configured Session Lifetime. Exceeding the configured period triggers a change from the Active to the Expired state.

Each Access Manager session holds the following attributes and applicable values for
(1) Session creation time and (2) Last access time, when a user accessed a resource or URL. Using these two values OAM and comparing with the configured values of Session Lifetime and Idle timeout settings, it performs the above Session check. 

From Oracle documentation: 

During transitions to the Idle state, underlying session attributes are preserved because the user previously satisfied authentication criteria and the data is trusted. However, continued access to protected resources based on that session, and resulting modification of data within that session, is not allowed until the user re-authenticates, proving not to be a malicious user with access to an unlocked computer.


User Session Lifecycle
The lifecycle of a user session refers to the period of user activity from the start of a user session to the end. Session lifecycle states include following 3 states - Active, Inactive, Expired.

Active: A session starts when the user is authenticated by Oracle Access Manager. The session remains active as long as the user makes requests for Oracle Access Manager-protected content, and provided that the session has not expired.

Inactive: A session becomes inactive when the user does not access OAM-protected content for the period defined by the Idle Timeout attribute in the session lifecycle configuration.

Expired: The duration of the session has exceeded the period defined by the Session Lifetime attribute.


An active session becomes inactive when the user is inactive for the defined Idle Timeout period. A session expires when it exceeds the defined Session Lifetime period.

Hope this post was helpful. If you have any further questions or have information to help improve this post then please provide your comments or inputs in the comments section and I will update the post.

References
[1] Managing Session, Chapter 14, Oracle Fusion Middleware Administrator's Guide for OAM
[2] Starting in OAM 12c (12.2.13) OAM configuration, oam-config.xml resides in the OAM Database. Refer chapter 5 Managing Data Sources OAM Admin Guide
[3] Error in OAM when viewing Session Management

Discussion in Oracle Forum

 Also check the OAM_Session Table which holds the current information about all the user sessions and its details. For example, >select * from oam_session     statement will give all the details of current user sessions at OAM. You can read this related discussion in Oracle Forum.