7 Managing Sessions

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

Prerequisites

The requirements for tasks in this chapter include:

Introduction to User Sessions and Session Management

Generally speaking, a user's visit to a Web site is referred to as a session. With Oracle Access Manager 11g, the user must be authenticated through Oracle Access Manager authentication services and must be accessing Oracle Access Manager-protected resources.

Oracle Access Manager 11g session management refers to the process of managing the lifecycle requirements of a user session, and notification of session events to enable global logout.

The Oracle Access Manager 11g 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 user session data 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.

Session data storage must be chosen during Oracle 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 Oracle 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.

  • A distributed in-memory cache shared by all managed Oracle 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 User Session Lifecycle", for more information.
  • OAM 11g requires a database to store OAM policy data and (optionally) OAM user session data. The database provides fault-tolerance and scaleability for very large deployments (with hundreds of thousands of simultaneous logins).

    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 OAM session data requires the database session store extended with the OAM-specific schema:

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

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

Oracle Access Manager 11g 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 "Oracle Coherence and Session Management".

Administrators can configure the user session lifecycle to define the maximum duration of a user 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 User 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 User Sessions".

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

About the User Session Lifecycle

User session lifecycle settings can be defined using the Oracle Access Manager 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).

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

User session lifecycle settings for OAM Agents can be defined using the Oracle Access Manager 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.

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

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

Note:

The Oracle Access Manager 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 Manager Console, an OAM Server must be running.

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

Session Data and Oracle Coherence Role
Description of "Figure 7-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.

Configuring User Session Lifecycle Settings

This section provides the following topics:

About Common Session Lifecycle Setting Page

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

Figure 7-2 Session Details: Common Settings Page

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

Table 7-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 7-1 Common Session Settings

Setting Description

Session Lifetime

The amount of time, in minutes, that a user's authentication session remains valid. When the lifetime is reached, the session expires.

Default = 480 minutes

A value of 0 disables this timeout setting. Any value between -2147483648 and 2147483647 is allowed.

Note: Session data for an expired session is automatically deleted from the in-memory caches (or database).

Idle Timeout

The amount of time, in minutes, that a user's authentication session remains valid without accessing any Oracle 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 0 disables this timeout setting. Any value between -2147483648 and 2147483647 is allowed.

Note: Session data for an inactive session is automatically deleted from the in-memory caches (or database).

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 value between 0 and 2147483647 is allowed.

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.


Viewing or Modifying Common Session Lifecycle Settings

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

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

Managing Active User 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

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

Figure 7-3 Common Configuration: Session Management Page

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

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

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

Session Search: Saved

If you choose Personalize, you can change the behavior of the saved search criteria by making new choices in the following window.

Session Search: Personalize

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 by AnonymousScheme, 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:

Session Controls: Userid and Client IP Address

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.

Session Search: Save...
  1. Enter a name, which will appear in the Saved Search list for later selection.

  2. Set this search as the Default (or clear the check box).

  3. Set this search to Run Automatically (or clear the check box).

  4. Save the Results Layout (or clear the check box).

  5. Click OK.

Add Fields

You can add different fields to your search form. The following list is available to assist.

Session Search: Add
  1. Click the Add Fields button.

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

Session Search: Time

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:

    Session Management Page View Menu
  • 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

Delete Button

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

Detach Button

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, OAM-generated session Id.

  • 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


Managing Active User Sessions

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

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

Verifying Session Management Operations

Use the following procedure to verify session management operations.

To validate session management

  1. Access a resource from a browser.

  2. In the Oracle Access Manager Console, verify that a user session exists, as described in "Managing Active User Sessions".

  3. Multiple Sessions:

    1. From a different browser (with cookies removed), access a different resource.

    2. Repeat Step 2 and confirm that two sessions exist.

  4. In the Oracle Access Manager Console, delete all user sessions, (Step 7 of "Managing Active User Sessions") and confirm that the active user sessions are removed.

  5. Re-authentication:

    1. From the browser in Step 3, attempt to access a different resource.

    2. Confirm that you are prompted for credentials.

  6. Verify that session data is created in the database:

    1. From the browser in Step 3, attempt to access a different resource.

    2. Confirm that you are prompted for credentials.

  7. Verify that session data is created in the database:

    1. Repeat Step 4 to delete all user sessions.

    2. Connect to the database as the OAM user and run the following query to get the results shown.

      SQL> select * from oam_session
      
    3. Confirm that you see the following results:

      1 row selected
      
    4. From the browser in Step 3, attempt to access a different resource.

    5. Connect to the database as the OAM user and run the following query

      SQL> select * from oam_session
      
    6. Confirm that you see one row of data:

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

  8. Optimize Logging for Session Management:

    1. Invoke WLST for your platform from the following path. For example:

      MW_HOME/oracle_common/common/bin/wlst.sh
      
    2. Connect to WLST and login.

    3. Execute domainRuntime() and setLogLevel(target="oam_server1",logger="oracle.oam.engine.session",level="FINEST",addLogger=1)

    4. Tail the file <domainhome>/servers/oam_server1/logs/oam_server1-diagnostic.log.

    5. Perform session operations.

    6. View log messages for the Session Management Engine and Session store modules.

    7. Repeat Step c to set level="SEVERE", perform operations and view log messages.

Security

This section discusses session security for Oracle Access Manager 11g:

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.

Database Persistence for Active Sessions Enabled appears in the Oracle Access Manager Console, as described in Table 7-1.