The following topics provide an overview of server-side session management:
Session security begins with a secure installation.
For installation details see the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
See Also:
Administering Oracle Fusion Middleware for details about configuring secure communications between Oracle Fusion Middleware components using SSL.
The HTTPS protocol, Oracle Coherence and database encryption are some of the ways in which Access Manager supports server-side session security. The following list describes how this support can work.
HTTPS Protocol
Access Manager helps prevent session fixation by providing IP address checks by the Proxy. To further help prevent session fixation, be sure to use the secure HTTPS protocol for communication between WebGates and OAM Servers.
Oracle Coherence
Data is not encrypted in-memory; however, data is protected over the wire. Oracle Coherence communicates between the different Access Manager instances on various servers, and this communication is secured in the following ways.
Coherence supports communication only between hosts that have been previously identified. This is done as a range of IP addresses, or by specific host names. Access Manager configuration files contain entries for each server that participates in the communication. During startup, this information is provided to Coherence ensuring that only authorized servers participate in the communication.
Coherence uses mutually-authenticated SSL between all servers in the cluster. The jceks keystore file, which holds the applicable keys and certificates, is created during installation.
See "Access Manager Sessions and the Role of Oracle Coherence" as well as the Oracle Coherence documentation.
Database Encryption
The Session Management Engine does not encrypt data. For security concerns, use an in-database encryption such as Oracle Advanced Security.
The session lifecycle refers to a set of states with defined transitions from one state to another that depend on user activity (or lack thereof), and manual (or automated) Administrator activity.
Administrators can define the following global session lifecycle settings:
Session Lifetime
Idle Timeout
Maximum number of Sessions
Database Persistence of Active Sessions
Note:
Idle Timeout can also be implemented as application-specific settings, as described later.
Table 16-1 lists the Session lifecycle states.
Table 16-1 Session Lifecycle States
| State | Description |
|---|---|
|
Active |
Newly-created sessions are active. A session is created when the user is authenticated by Access Manager. The session remains active until Access Manager determines that the session must transition into one of the other states in this table. Note: Administrators can delete only active sessions. |
|
Idle |
An active session becomes idle when the user does not access Access Manager-protected content for the period defined by an Administrator. When an active session becomes idle, the user must re-authenticate to proceed. When re-authentication is successful, the session returns to the Active state; session attribute values are preserved through this process. |
|
Expired |
An active session expires when the duration of the session exceeds the defined lifetime. An expired session is completely inaccessible and eligible for deletion. When an active session expires, the user must re-authenticate to proceed. When re-authentication is successful, a new session is created; however, session attribute values are not preserved (as they are for Idle states). |
See the following topics for more information about:
Each Access Manager session holds two time attributes and applicable values.
Following are the two time attributes:
Session creation time
Last access time
The values of these attributes are compared for session enforcement as described in "Table 16-2".
Table 16-2 Session Checks for State 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. |
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.
A session can be removed by three actions: expiration, user logout, and termination.
Session removal actions are described in Table 16-3.
Table 16-3 Session Removal
| Action | Description |
|---|---|
|
Expiration |
Expired sessions are eligible for removal based on their creation time. Actual removal is determined by the storage mechanism. The session is removed from the distributed cache using a background task running on the server; it is removed from the database using a similar background task, an optionally-enabled job within the database itself, or both methods in combination. Once a session has been deleted from storage on all tiers (local and distributed caches, and from the database if enabled), the session is removed. |
|
User Logout |
User Logout triggers immediate removal from the distributed cache, subject to present volume of DB session writes and performance. |
|
Termination |
Termination is identical to user log out whether the session is interactively terminated through the Administration Console or in an automated way--as part of an Oracle Identity Management user lockout or de-provisioning flow. |
On occasion, multiple forms of authentication are required and performed within a single session to complete a step-up flow. A re-authentication level might be a step down from the session.
In a step-up flow, a user authenticates to access protected content and later in the same session, the user requests other, more sensitive content and is required to authenticate again to access it at a more stringent level. In a step-up flow, multiple authentications always occur in order of the increasing authentication level. Each session holds the Authentication Level attribute for step-up authentication enforcement.
If the re-Authentication Level is less than that previously contained in the session, the user has completed a step-down process. Upon successful re-authentication, the session is restored to the Active state with an Authentication Level that is equal to the lower level of the authentication scheme used. If the user later attempts to access content that is protected at a higher level, step-up authentication occurs.
Access Manager enforces limitations on user access to resources in a more granular way than is possible with a single set of global session timings, or single set of authentication schemes in which access depends solely on a single authentication level. Access to certain data has more stringent requirements, while access to all other data is configured globally.
Administrators can choose to override global session timeout settings on a per application basis, defined as part of Application Domain settings. Optional application-specific session configuration provides:
The ability to declare session idle timings on a per-application basis, which is generally more stringent than the global idle timing defined within the deployment as a whole.
The ability to require the user to re-authenticate after a per-application session inactivity timeout.
Table 16-4 describes session enforcement when you have defined Application Domain-specific overrides to global session settings.
Table 16-4 Application Domain-Specific Overrides
| Override | Description |
|---|---|
|
Is the Session Idle? |
Compares the last access time against the configured Idle Timeout value for the defined Application Domain only. 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 for the defined Application Domain group only. |
The idle timeout is applied appropriately even if the session is operating in a disconnected state. (A disconnected state occurs if mod_osso requests are being made but not by the WebGate. In this case, the session appears to have idled out to the server.) To enable global logout for the OSSO Agent, the Session Management Engine reconciles a period of inactivity with the OAM Agent against a period of activity with the OSSO Agent.
mod_osso agents support granular timeout only if the Global Inactivity TimeOut feature is enabled (using the editGITOValues WLST command). The OAM_GITO cookie is needed in special cases to support timeout with multiple types of agents working with OAM Server (such as mod_osso and WebGate). If a user leaves an active session (with an OAM Agent), starts a session with an OSSO Agent, and then returns to the initial session (with the OAM Agent, now inactive), the Session Management Engine reconciles the period of inactivity with the OAM Agent against the period of activity with the OSSO Agent to enable global logout for the OSSO Agent.
Note:
Oracle strongly recommends that you change the value of the Idle Timeout parameter when using the OAM_GITO cookie:
Login to the OAM Console as administrator.
Click the System Configuration tab.
Click Common Settings.
Change the value for the Idle Timeout parameter (in the Session section) so that it matches the value of the OAM_GITO cookie as defined.
The OAM_GITO cookie is enabled and configured using the editGITOValues WLST command. For details, see the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for Identity and Access Management.
Access Manager sessions can be configured as Persisted or Distributed sessions.
The default Access Manager configuration is the Persisted Sessions but you can use the Oracle Access Management Console to change this.
When Access Manager is configured for Persisted Sessions, all user sessions are stored in a backing database and are available across server restarts. Recently created sessions and the most frequently used sessions will also be stored in memory in the Coherence cache. The sessions are written out to the database in a batched mode in an asynchronous thread, enabling faster latencies during session creation and updates. When requested by the server, the Coherence cache transparently fetches either its local copy or the copy stored in the backing database based on the number of cache hits at the time. The size of the in-memory cache can be small enough to accommodate active sessions. The size of the Coherence cache is configurable; by default, it is defined as 100 MB.
When Access Manager is configured for Distributed Sessions, the user sessions are stored only in the in-memory Coherence Cache. These sessions are not available across server cluster restarts. However if any specific node is stopped, the backup sessions of that node will used. The total sessions retained are restricted to the size of the Coherence cache - configurable using the Oracle Access Management Console. If more users login than can be stored in the cache, the oldest non-active sessions are deleted from the cache. A user whose session has been deleted from the cache will have to login again to be recognized and granted access to protected resources.
The Coherence cache size required for either of the described configurations is calculated using the following formula.
S = N * (1 + b) * s / n
S is the size of heap to be allocated to the Coherence Session cache per OAM server. The size of the heap allocated to sessions per OAM node may be updated in the OAM configuration file under the Setting element name DistributedCacheMaxSize. This update to the configuration requires, at the least, a rolling restart of the servers.
N is the maximum number of sessions to be stored in the cache.
b is the number of backup copies.
s is the average size of a session object. The average size of a session object may vary based on attributes and responses that are stored in the session. This value may be discovered in any installation by examining the Coherence mbeans for backing store of SmeNearCache cache.
n is the number of OAM server nodes that participate in the cluster.