12 Managing Sessions

About the User Session Lifecycle

User session lifecycle settings can be defined using the OAM Administration Console. The WebLogic Scripting Tool does not include options for session management.

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:

• 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.

The Session Management Engine maintains a list of inactive sessions. When an active session becomes inactive, or expires, the user must re-authenticate. Data for expired sessions is automatically deleted from in-memory caches (or the optional SME database). Administrators can delete only active-user-session data.

OSSO GITO Support: The GITO cookie is needed in special cases to support timeout with multiple types of agents (mod_osso and WebGate) working with OAM 11g Server. When enabled (using the editGITOValues WLST command), if a user leaves an active session (with an OAM Agent) and starts a session with an OSSO Agent, when he 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. The idle timeout is applied appropriately even if the session is operating in a disconnected state (mod_osso requests are being made but none are made by WebGate; to the server, the session appears to idle out).

User session lifecycle settings for OAM Agents can be defined using the OAM Administration Console. The WebLogic Scripting Tool does not include options for session management.

Oracle Coherence and Session Management

This section describes how the embedded Oracle Coherence data management and caching service is used during session management with the in-memory caches and any database that is configured as an SME session data store.

Oracle Coherence replicates and distributes session data across all Managed Servers in the cluster. The location of session data is transparent to the client. Oracle Coherence traffic is automatically encrypted. The Session Management Engine exposes session objects to other Oracle Access Manager components as needed. To compensate for data latencies and account for serialization and network transmission of objects, the cache is configured as a near cache to maintain short-lived session objects at the point of consumption.

Oracle Coherence also performs failover and reconciliation. For example, if one Managed Server fails, Oracle Coherence automatically distributes data from the failed host to the distributed in-memory caches of other Managed Server hosts.

Figure 12-1 illustrates the storage of session data that occurs using embedded Oracle Coherence. A description follows the diagram.

Figure 12-1 Session Data and the Role of Oracle Coherence

Description of "Figure 12-1 Session Data and the Role of Oracle Coherence"

Process overview: SSO session data storage after successful authentication

1. The session is created, a sessionID is assigned, and session data is stored in the distributed in-memory cache. A copy is available for a short time in the local in-memory cache on the computer hosting the resource (Managed Server 1 in this example).

2. After a brief period, the local in-memory cache transfers the session data to the distributed in-memory cache on the same host.

   Note:

   If the distributed in-memory cache runs out of allocated memory space, then the least recently used sessions are evicted from the cache and stored in the database if one was configured. If the Session Management Engine is configured to use just the distributed session store, then the sessions are put in a flat file.

3. With each session change, Oracle Coherence updates, replicates, and distributes session data in the distributed cache among OAM Servers (Managed Server 2 in this example).

   Note:

   The same session data is stored on only two hosts (the original host and one other).

4. Oracle Coherence also distributes session data from the host of origin to the optional database store, if you are using one.

   Note:

   Only session data from the host of origin is written to the database store.

5. A new resource request is made and session data is stored in the local in-memory cache on the computer hosting the resource (Managed Server 3 in this example).

6. After a brief period, the local in-memory cache transfers the session data to the distributed in-memory cache on the same host (Managed Server 3 in this example).

7. With each session change, Oracle Coherence updates, replicates, and distributes session data in the distributed cache among OAM Servers (Managed Server 2 and the optional SME database store).

   Note:

   The same session data is stored on only two hosts (the original host and one other). Only session data from the host of origin is written to the database store.

8. A user requesting an OSSO-protected resource occurs within the same active session used by OAM Agents; however, only the OSSO user login and logout are recognized by the OAM Server. You can enable co-existence between agents.

   Note:

   A user can access an OSSO-protected resource while working on OAM-protected resources. Leaving the OAM-protected resource can cause an idle session timeout. However when she returns to the OAM-protected resource, Oracle Coherence reconciles the period of inactivity in the OAM Agent session against the period of activity with the OSSO Agent to enable global logout.

About Common Session Lifecycle Setting Page

User-session lifecycle settings are part of the OAM Server Common Properties shared by all OAM Servers. Figure 12-2 shows the lifecycle attributes that you can configure.

Figure 12-2 Session Tab under OAM Server Common Properties

Table 12-1 describes common 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. 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.

Viewing or Modifying Common Session Lifecycle Settings

Users with valid OAM Administrator credentials can use the following procedure to modify common session lifecycle settings using the OAM Administration Console.

To view or modify common session lifecycle settings

1. From the Oracle Access Manager Administration Console, click the System Configuration tab.

   The System Configuration navigation tree appears.

2. In the navigation tree, double-click Server Instances.

3. On the OAM Server Common Settings page, click the Session tab to display lifecycle settings.

4. Click the arrow keys beside each list to increase or decrease session lifecycle settings as needed (Table 12-1):

   • Session Lifetime

   • Idle Timeout

   • Maximum Number of Sessions per User

5. Click Apply to submit the changes (or close the page without applying changes).

6. Close the page when you finish.

7. Proceed to "Managing Active User Sessions".

About the Session Management Page

Figure 12-3 illustrates the Session Management page, under the System Configuration tab, System Utilities node. Additional details follow the figure.

Figure 12-3 Session Management Page, under System Utilities

Description of "Figure 12-3 Session Management Page, under System Utilities"

Table 12-2 describes Session Management page controls the results table.

Table 12-2 Session Management Page Controls and the Results Table

Tool Bar Icon	Name	Description
N/A	Delete All User Sessions ...	Choose this command button to delete the active sessions of all users. Note: A Confirmation window appears where you can confirm or decline the operation.
N/A	Username	Enter a specific userID in the field and then click the > button to display all active sessions for this user. Note: A complete and accurate userID is required. No wild cards are allowed and no automatic fill-in occurs.
N/A	Tool Bar	Choose commands from the provided menu or command buttons in the tool bar above the results table.
View	View menu	Choose commands from the View menu above the results table to configure the table. Commands include: Columns: Displays a menu with the following options you can use to hide or display specific details in the table: Show All Session ID IP Creation Time Last Accessed Last Updated Detach: Expands the results table to a full-screen view Attach: Restores the Session Management page view. Reorder Columns: Specifies a new order for columns containing session data in the results table.
	Delete	Choose this command button after selecting items in the results table to delete. Note: A Confirmation window appears where you can confirm or decline the operation.
	Detach	Click to expand the results table to a full-page view. Note: If the table is already a detached full-page, click Detach to restore the Session Management page.
N/A	Results table (not named)	After searching for the active sessions of a specific user, results are displayed in the table. Details include: Session ID: A unique, OAM-generated session Id. IP: The IP address of the specified user. Creation Time: The day and time the session was created. Last Accessed: The day and time the session was last accessed Last Updated: The day and time the session was last updated due to a change.

Managing Active User Sessions

Users with valid OAM Administrator credentials can use information in the following procedure to configure the search results table, locate the active sessions of a specific user, delete one or more sessions for a specific user, or delete all sessions for all users.

Skip any steps that do not apply to your requirements.

Prerequisites

OAM Server must be running.

To locate and manage active sessions

1. From the Oracle Access Manager Administration Console, click the System Configuration tab.

   The System Configuration navigation tree appears.

2. In the navigation tree, click System Utilities.

3. Under System Utilities, double-click Session Management.

   The Session Management page appears with the Username field and a results table.

4. Configure the Results Table:

   1. Click View to open the View menu, then click Columns to open the options list.

   2. In the options list, click to check (or clear) items to display (or remove) from the table.

   3. Review the results table to confirm the new setup.

5. Find sessions for a specific user:

   1. In the Username field, enter an exact userid.

   2. Click the > button on the right to locate sessions for this user.

   3. Review the results table.

   4. Detach Results Table: Click the Detach command button (or select Detach from the View menu) to display only the table.

6. Delete sessions for a specific user:

   1. In the results table, click one or more sessions for the user.

   2. Click the Delete button to delete the selected sessions.

   3. Click Yes to confirm deleting selected sessions (or click No to cancel the delete operation).

   4. Notify the user, if needed.

7. Delete sessions for all users:

   1. Click the Delete All User Sessions button in the upper-right corner.

   2. Click Yes when you are asked to confirm.

8. Close the Session Management page when you finish.

9. Proceed to "Verifying Session Management".

Secure HTTPS Protocol

Oracle Access Manager 11g helps prevent session fixation by providing IP address checks by the Proxy. To further help prevent session fixation, use the secure HTTPS protocol.

Coherence

Data is not encrypted in-memory; however, data is protected over the wire. Coherence communicates between the different OAM instances on various servers. This communication is secured by the following two 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. OAM configuration file contains entries of the servers that participate in the communication. During startup, this information is provided to coherence to ensure that only authorized servers participate in the communication.

• Coherence supports network filters that apply to all communication. Custom filters can be plugged in to provide filtering of required nature

  OAM provides a custom filter that ensures that all communication that occurs between the instances is encrypted/decrypted with a shared key. This 128-bit key is available in the jceks and generated during install

For more information, see the Oracle Coherence documentation.

Database Persistence

The Session Management Engine does not encrypt data.

Session data is not encrypted by Session Management Engine when written to the database.

If you have concerns, use an in-database encryption such as Oracle Advanced Security.