Session Lifecycle settings can be defined using the Oracle Access Management Console. When you define either global or application-specific session lifecycle settings, any timing interval set to 0 cancels the corresponding check.
For example if idle timeout is set to 0, sessions never idle out. With a session lifetime of 0, sessions never expire. In all cases, applicable data is tracked and updated in the session, just as if it is being checked on a per-request basis.
This section provides the following topics:
Access Manager session lifecycle settings are defined as part of the Common Settings shared by all OAM Servers.
Figure 16-1 shows the lifecycle attributes that you can configure on the Common Settings page.
Figure 16-1 Global Session Details: Common Settings Page
Table 16-7 describes the global session lifecycle 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. To apply changes immediately, Oracle recommends that you terminate existing sessions and force users to create new ones that adhere to your new rules.
See Also:
Table 16-7 Global 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. Note: Timed-out sessions are not deleted from the session manager. Session data could be removed from memory but will still be available in the persistant store (database). After re-authentication, the same session will be re-activated. See Also: "Application-Specific Session Overrides" |
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 Tuning Performance. |
(Management) Maximum Search Results |
Maximum number of sessions fetched by default for a session query if the result set is large. |
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. |
Application-specific access is tracked from the initial application-access time and is updated only as further requests are made of that Application Domain.
In other words, the user's authentication and the authentication state are under control of Access Manager and the Administrator. The current idle time for a given application is shared between Access Manager and the application. The application provisions its own run time data for the user on a per-session basis and needs to remove it as soon as possible to make room for others.
Administrators can add application-specific session overrides on the Summary tab of an Application Domain. Table 16-8 lists application-specific settings that, when specified, override global session settings.
Table 16-8 Application-Specific Session Timing Overrides
Element | Description |
---|---|
Idle timeout |
Access Manager previously stored the last access time value within the session. To enforce maximum idle time on a per-application basis, Access Manager includes a new application-specific last access time field to hold it. This is filled with the last access time for each subset of domains visited within the course of a session, on which a per-application idle timeout override has been defined. This is not needed for domains on which an override has not been defined--no checking is done against such data. Default: undefined Note: When the app domain timeout value is less than the global session timeout value and it is more restrictive, the app domain idle timeout overrides the global session idle timeout. When it is greater than global session timeout, OAM session timeout is based on the Global Settings value. |
For more information, see "Viewing or Modifying Optional Application-Specific Session Overrides".
Users with valid Administrator credentials can to modify common session lifecycle settings using the Oracle Access Management Console.
For more information, see "Global Session Lifecycle Settings"
Users with valid Administrator credentials can modify optional session settings for one or more application domains in a named group.
For more information, see "Application-Specific Session Overrides".