14 Managing Sessions

This chapter describes session concepts and procedures for Access Manager. This chapter includes the following topics:

• Prerequisites

• Introduction to Sessions and Session Management

• Configuring Session Lifecycle Settings

• Managing Active Sessions

• Verifying Session Operations

14.1 Prerequisites

The requirements for tasks in this chapter include:

• Reviewing "Introduction to Sessions and Session Management"

• Getting familiar with Chapter 5, "Managing Server Registration"

• Getting familiar with Chapter 2, "Getting Started with Oracle Access Management Administration and Navigation"

14.2 Introduction to Sessions and Session Management

Generally speaking, a user's visit to a Web site is referred to as a session. With Access Manager, the user must be authenticated through Access Manager authentication services and must be accessing Access Manager-protected resources. An Access Manager session created is bound to both a user and the client with which they have authenticated.

The Access Manager session lifecycle consists of state transitions for session creation, updates, idleness, and expiration. Access Manager sessions are maintained within OAM Servers to provide tracking and policy enforcement for a given session's lifecycle (performed either manually by an Administrator and using automated flows).

Access Manager session management refers to the process of managing the lifecycle requirements of a session, and notification of session events to enable global logout. Administrators can configure Access Manager session lifecycle settings using the Oracle Access Management Console.

The Access Manager Session Management Engine (SME) interfaces with the SSO engine, which acts as the controller for session events and notifications. SME services enable the automatic generation, update, and management of a session and enable Administrators to configure the session lifecycle and to locate and remove specific active sessions.

Note:

You can access resources protected by both registered OAM Agents and OSSO Agents during the same session.

The Session data storage must be chosen during Access Manager installation and configuration. The same storage mechanism applies to all servers in a cluster and can be changed after installation.

Session data is stored in multiple tiers to balance latency, availability, and resource consumption. These include:

• The local in-memory cache of each managed Access Manager server.

  This cache contains session data for use in active server requests. A short TTL is used to quickly evict data that is not currently used. This cache uses embedded technology from Oracle Coherence to provide a distributed cache with low-data access latencies and to transparently move data between distributed caches (and the database).

• A distributed in-memory cache shared by all managed Access Manager servers.

  This cache contains session data that has been serialized for management by Oracle Coherence. Using Coherence, session data is available to any managed server that an Agent can contact to make access requests involving a session. Coherence also replicates this data across the running servers to provide fault-tolerance. Entries in the distributed cache are evicted not based on a TTL, but overall cache memory size as applied on a per-machine basis.

  If the maximum cache memory size is reached, one of two actions are taken:

  • If the session store is enabled, entries are evicted from the distributed cache to make room. They continue to exist in the database, and can be brought back into the distributed cache if needed.

  • If the session store is not enabled, as a fallback mechanism entries are written to a flat file on the local machine. As the number of entries in this file grows, along with their percentage of the total number of active sessions, performance will degrade accordingly.

  Note:

  When a user logs out, or when the session expires, session data is automatically deleted from the in-memory store. See "About the Session Lifecycle", for more information.

• Access Manager requires a database to store Access Manager policy data and (optionally) Access Manager session data. The database provides fault-tolerance and scaleability for very large deployments (with hundreds of thousands of simultaneous logins). You must be using a database policy and session-data store that is extended with the Access Manager-specific schema

  The latest data is written to the session store with each session change (step-up authentication is one example of a session change). This is done asynchronously, and so does not affect latency for the request causing the session to be created or updated. Session data is available even if an unanticipated power failure occurs.

  To store Access Manager session data requires the database session store extended with the Access Manager-specific schema:

  • Use RCU with the Access Manager-specific schema to set up a database as a policy and session data store.

  • Use Access Manager with Database Policy Store configuration template to enable Access Manager to use the database as a policy and session data store.

Access Manager uses Oracle Coherence to provide a distributed cache with low-data access latencies and to transparently move data between distributed caches (and into the session store). Session data is redundant across these tiers. For example, when a session is created, it then exists within the local cache on the server that created it, the distributed cache, and (if enabled) within the session store database as well. For more information, see "About Oracle Coherence and Session Management".

Administrators can configure the session lifecycle to define the maximum duration of a session, the period of inactivity before the user must re-authenticate, and the maximum number of active sessions each user have. The session expiration configuration enables inter-operability with OSSO Agents (mod_osso), which are only visible to the server during user login and logout. For details, see "Configuring Session Lifecycle Settings".

Each session is unique and is identified with both a userID and a sessionID to distinguish different sessions for the same user. Administrators can find and delete one or more active sessions for a particular user or for all users. For example, a user with too many open sessions can contact the Administrator and request that some or all of his sessions be removed so he can start fresh. For more information, see "Managing Active Sessions".

Access Manager uses Oracle Coherence to replicate session states within a distributed installation. Coherence is used to communicate state changes between the Oracle Access Management Console and OAM Servers. Coherence relies on User Datagram Protocol (UDP) for cluster discovery and heartbeat. If a firewall exists between certain components, then the corresponding UDP ports used by Coherence must be open. Otherwise, Access Manager might not work correctly. For more information, see "Using Coherence".

14.2.1 About Access Manager Session Security

Session security begins with a secure installation that includes time synchronization among servers. For installation details see the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

See Also:

Oracle Fusion Middleware Administrator's Guide for details about configuring secure communications between Oracle Fusion Middleware components using SSL.

This section discusses Access Manager session security:

• Secure HTTPS Protocol

• Oracle Coherence

• Database Persistence

14.2.1.1 Secure 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.

14.2.1.2 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. 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 uses mutually-authenticated SSL between all servers in the cluster. The jceks, which holds applicable keys and certificates, is created during installation.

For more information, see the Oracle Coherence documentation.

14.2.1.3 Database Persistence

The Session Management Engine does not encrypt data. For security concerns, use an in-database encryption such as Oracle Advanced Security.

14.2.2 About the Session Lifecycle

Session lifecycle settings can be defined using the Oracle Access Management Console. The WebLogic Scripting Tool does not include options for session management.

The lifecycle of a session refers to the period of user activity from the start of a session to the end. Session lifecycle states include:

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

• Inactive: A session becomes inactive when the user does not access Access Manager-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 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).

Note:

The Session Management Engine reconciles a period of inactivity with the OAM Agent against a period of activity with the OSSO Agent to enable global logout for the OSSO Agent. For more information, see "mod_osso Cookies".

Session lifecycle settings for OAM Agents can be defined using the Oracle Access Management Console. The WebLogic Scripting Tool does not include options for session management.

14.2.3 About Timeout with Multiple-Agent Types: OSSO and OAM Agents

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

The Session Management Engine reconciles a period of inactivity with the OAM Agent against a period of activity with the OSSO Agent to enable global logout for the OSSO Agent. For more information, see "mod_osso Cookies".

The GITO cookie is needed in special cases to support timeout with multiple types of agents (mod_osso and Webgate) working with OAM 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.

14.2.4 About OpenSSO Agents

In the context of session management, OpenSSO agents are equivalent to Webgates.

Unlike mod_osso, OpenSSO Agents do not operate in a disconnected state.

14.2.5 About 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.

Note:

To maintain the shared session state consistent among the OAM Servers, the Coherence infrastructure requires network connectivity between the cluster members. Oracle recommends the use of redundant networking infrastructure in deployments requiring Access Manager session data consistency in the presence of network component failures.

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

Note:

Oracle Coherence traffic is automatically encrypted.

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 14-1 illustrates the storage of session data that occurs using embedded Oracle Coherence. A description follows the diagram.

Note:

The Oracle Access Management Console is an application that resides on the WebLogic AdminServer. Session data is not stored on the AdminServer. To perform session management operations from the Oracle Access Management Console, an OAM Server must be running.

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

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

Process overview: SSO session data storage after successful authentication

1. The session is created in the distributed in-memory cache. A copy is available in the local in-memory cache on the computer hosting the resource (Managed Server 1 in this example). The session is also written to the database.

2. With each session change, Oracle Coherence updates, replicates, and distributes the session in the distributed cache among OAM Servers (Managed Server 2 in this example). By default, each change is also written to the database.

3. A new resource request is made and the session is read into the local in-memory cache on the server hosting the resource (Managed Server 3 in this example).

14.3 Configuring Session Lifecycle Settings

This section provides the following topics:

• About Common Session Lifecycle Setting Page

• Viewing or Modifying Common Session Lifecycle Settings

14.3.1 About Common Session Lifecycle Setting Page

User-session lifecycle settings are part of the Common Settings shared by all OAM Servers. Figure 14-2 shows the lifecycle attributes that you can configure on the Common Settings page.

Figure 14-2 Session Details: Common Settings Page

Description of "Figure 14-2 Session Details: Common Settings Page"

Table 14-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.

Table 14-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.

14.3.2 Viewing or Modifying Common Session Lifecycle Settings

Users with valid Oracle Access Management Administrator credentials can use the following procedure to modify common session lifecycle settings using the Oracle Access Management Console.

See Also:

"About Common Session Lifecycle Setting Page"

To view or modify common session lifecycle settings

1. From the System Configuration tab, expand the Common Configurations section, and double-click Common Settings.

2. On the Common Settings page, expand the Session section.

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

   • Session Lifetime

   • Idle Timeout

   • Maximum Number of Sessions per User

4. Check the box to enable Database Persistence for Active Sessions.

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 Sessions".

14.4 Managing Active Sessions

The Session Management page provides Search controls that enable Administrators to create a query based on filter conditions, save their Search Criteria for use later, and add fields to the query form to further refine the search.

In the database store configuration, the session might exist in the database but not in the cache. Session searches are based on the system time stamp. The database is queried for sessions updated earlier than the time stamp (minus the write delay). The cache is queried for sessions updated later than this time stamp. Resulting data found in the cache and the database is merged. If duplicate results exist, cache data prevails. Detailed performance metrics are generated for search operations.

This section describes how to locate and delete one or more sessions for a single user, or for all users. It provides the following information:

• About the Session Management Page

• Managing Active Sessions

14.4.1 About the Session Management Page

Figure 14-3 illustrates the Session Management page, under the System Configuration tab, Common Configuration section. Additional details follow the figure.

Figure 14-3 Common Configuration: Session Management Page

Description of "Figure 14-3 Common Configuration: Session Management Page"

Table 14-2 describes Session Management page and Search controls that enable you to create a query that is based on filter conditions that you choose.

Table 14-2 Session Management Controls and the Results Table

Name	Description
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.
Saved Search	Lists any search criteria saved previously for reuse. A list like the following is made available whenever you save search criteria. If you choose Personalize, you can change the behavior of the saved search criteria by making new choices in the following window.
Match All Any	Enables you to match either any of the criteria you have specified or match all of the criteria you have specified during the search. Note: When a resource is protected byAnonymousScheme, it is not displayed in a session search.
Userid	Enter a specific userID in the field and then click the Search button to display all active sessions for this user. Incomplete strings and wild cards are allowed. The following list is available to assist your search:
Client IP Address	Enter a Client IP Address and then click the Search button to display all active sessions for this user. Incomplete strings and wild cards are allowed. The same list is available to assist your Userid search and your Client IP Address.
Search	Click this button to initiate a search based on criteria in the form.
Reset	Click this button to clear the form of all criteria.
Save	Click this button to initiate a save operation that enables reuse of your search criteria. The following window opens. Enter a name, which will appear in the Saved Search list for later selection. Set this search as the Default (or clear the check box). Set this search to Run Automatically (or clear the check box). Save the Results Layout (or clear the check box). Click OK.
Add Fields	You can add different fields to your search form. The following list is available to assist. Click the Add Fields button. Click items in the list to add them to the form and click Save. After adding an item, notice that a list is available to assist with the search. For example: Employment and time-based selections provide the following list.
View	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: 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: When session search criteria is generic (using just a wild card (*), for example), there is a limitation on deleting a session from a large list of sessions. Oracle recommends that your session search criteria is fine-grained enough to obtain a relatively small set of results (ideally 20 or less). Also: 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.
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, generated session identifier. User ID: Impersonating: Creation Time: The day and time the session was created. Last Accessed: The day and time the session was last accessed Client IP: The IP address of the specified user. ID Store Impersonator

14.4.2 Managing Active Sessions

Users with valid Oracle Access Management 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.

When a resource is protected by AnonymousScheme, it is not displayed in a session search.

See Also:

"About the Session Management Page"

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 System Configuration tab, Common Configuration section, open the Session Management node.

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

2. Add Fields: From the Add Fields list, choose the desired field name (Table 14-2).

3. Choose Operators: Open the list of operators for the chosen search field, and choose the desired function.

4. Find sessions:

   1. In the desired query field, enter your criteria (with or without a wild card (*)).

   2. Click the Search button to locate sessions that match either any or all your criteria.

   3. Review the results table.

   4. Repeat if needed to further refine your search.

5. Configure the Results Table: Use functions on the View menu to create the desired results table.

6. Delete sessions:

   1. In the results table, click one or more sessions to remove.

   2. Click the Delete (x) 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 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 Operations".

14.5 Verifying Session Operations

Use the following procedure to verify session management operations.

To validate session management

1. Authenticate:

   1. Access a resource from a browser using a credential other than your Administrative credential.

   2. Verify that the session exists, as described in "Managing Active Sessions".

2. Multiple Sessions:

   1. From a second browser (with cookies removed), access the same resource.

   2. Verify that two sessions exist.

3. Delete all sessions, (Step 7 of "Managing Active Sessions") and confirm that the Active sessions are removed.

4. Re-authentication Verification:

   1. From the second browser (Step 2), access a different resource to confirm that you must re-authenticate.

   2. Enter credentials for the resource.

   3. Verify that a session was created.

5. Database Verification:

   1. Delete all sessions.

   2. Connect to the database and run the following query:

      SQL> select * from oam_session
      

   3. Confirm that you see the following results:

      no row selected
      

   4. From the second browser, access a different resource.

   5. Connect to the database and run the following query

      SQL> select * from oam_session
      

   6. Confirm that you see one row of data:

      1 rows selected
      

   7. Select rows from OAM_SESSION_ATTRIBUTES and confirm that data exists for the user.