17 Maintaining Access Manager Sessions

An Access Manager session is created during authentication and bound to both the user and the client with which the user has authenticated. Access Manager sessions are maintained to provide tracking and policy enforcement (performed either manually by an Administrator or using automated flows) for a given session's lifecycle. The Access Manager session lifecycle consists of state transitions for session creation, updates, idleness, and expiration.

This chapter describes concepts and procedures for Access Manager sessions.

• Introducing Access Manager Session Management

• Understanding Server-Side Session Management

• Server-Side Session Enforcement Examples

• Configuring the Server-Side Session Lifecycle

• Managing Active Server-Side Sessions

• Verifying Server-Side Session Operations

• Understanding Client-Side Session Management

• Using WLST To Configure Session Management

17.1 Introducing Access Manager Session Management

With this 11gR2 PS2 release of Oracle Access Management, Access Manager sessions can be managed from either the server side or the client side.

• Server-side session management (also referred to as Coherence-based session management) is the default session management option developed for Access Manager. It allows for advanced session management across nodes via Coherence-based caching. Offering reliable performance and advanced features (including impersonation, session sniping, identity context propagation and the like), server side session management is recommended for most deployments - especially internal ones where rich session management features are desired. More details are documented in:

  • "Understanding Server-Side Session Management"

  • "Server-Side Session Enforcement Examples"

  • "Configuring the Server-Side Session Lifecycle"

  • "Managing Active Server-Side Sessions"

  • "Verifying Server-Side Session Operations"

• Client-side session management (also referred to as cookie-based session management) manages sessions using browser cookies; it is essentially stateless. Client side session management offers higher performance with a lightweight footprint when compared to the Coherence-based option. It stores session details in the browser cookie with no information saved on the server-side and is most appropriate for very large deployments where advanced server-side session management features are not needed. More details are documented in "Understanding Client-Side Session Management".

  Note:

  Cookie-based sessions can be accessed only from a browser request context and not directly from the server.

See "Using WLST To Configure Session Management" for instructions on how to configure the session management option.

17.2 Understanding Server-Side Session Management

This section provides the following topics:

• Securing Access Manager Sessions

• Understanding the Access Manager Session Lifecycle, States, and Enforcement

• Access Manager Sessions and the Role of Oracle Coherence

17.2.1 Securing Access Manager Sessions

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:

Oracle Fusion Middleware Administrator's Guide 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.

  For more information, 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.

17.2.2 Understanding the Access Manager Session Lifecycle, States, and Enforcement

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.

Session lifecycle states include those in Table 17-1.

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

For more information, see the following topics:

• About Global Session Enforcement Checks

• About Session Removal

• About Step-Up and Step-Down Authentication and Credentials

• About Optional Application-Specific Session Enforcement

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

• About OpenSSO Agents

17.2.2.1 About Global Session Enforcement Checks

Each Access Manager session holds the following attributes and applicable values.

• Session creation time

• Last access time

The values of these attributes are compared for session enforcement as described in Table 17-2.

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

17.2.2.2 About Session Removal

A session can be removed by any of the actions described in Table 17-3.

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

17.2.2.3 About Step-Up and Step-Down Authentication and Credentials

On occasion, multiple forms of authentication are required and performed within a single session to complete a step-up flow. 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.

A re-authentication level might be a step down from the session. 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.

17.2.2.4 About Optional Application-Specific Session Enforcement

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 17-4 describes session enforcement when you have defined Application Domain-specific overrides to global session settings.

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

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

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

17.2.3 Access Manager Sessions and the Role of Oracle Coherence

This section describes how the embedded Oracle Coherence data management and caching service interacts with the session stores during session management. This might include the local and distributed (serialized) in-memory caches and an optional database if one is configured and enabled as the Session Management Engine session store.

Note:

Generally, both the AdminServer and OAM Servers participate in the Oracle Coherence cluster. However, AdminServer does not access session data except when performing searches.

Access Manager uses Coherence to replicate session states within a distributed installation. Coherence is used to communicate state changes between the 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.

Note:

To maintain a consistent shared session state among the OAM Servers, the Coherence infrastructure requires network connectivity between 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 the session is transparent to the client. The Session Management Engine exposes session objects to other components as needed.

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

Although the Oracle Access Management Console resides on the WebLogic AdminServer, sessions are not stored there. Figure 17-1 illustrates session storage using an embedded Oracle Coherence.

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

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

The session is stored on two hosts. If the distributed cache runs out of allocated memory space, the oldest sessions are evicted from the cache. If the Session Management Engine is configured to use just the distributed cache, evicted sessions are recorded in a flat file to avoid loss. The following list is an overview of how session data is stored after a 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). If session persistence to database is enabled, 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).

17.3 Server-Side Session Enforcement Examples

Satisfying the authentication scheme of a given level provides access to all resources protected at lower levels. Additionally, all authentication schemes of a given level are viewed as equivalent. This section provides a simple session enforcement example based on a single authentication scheme used in two application domains as well as a more complex example based on multiple authentication schemes used in two application domains.

• Example 1: Single Authentication Scheme

• Example 2: Multiple Authentication Schemes

• Access Manager Sessions and the Role of Oracle Coherence

17.3.1 Example 1: Single Authentication Scheme

Consider the following configuration:

• A single authentication scheme (S1) defined using Level 2

• Application domains D1 and D2

• All resources within each domain are protected with a single authentication policy, which uses S1, and a single authorization policy.

• Global Session Configuration:

  • Session Lifetime: 90 minutes

  • Idle Session Timeout: 0 (session never idles out)

  • Application Domain Timeout: 30 minutes

Now consider the outcomes in Table 17-5.

Table 17-5 Session Content: Single Authentication Scheme

Time (Delta)	Action	Access Allowed or Denied	Session Content
0	Access to D1	Denied due to no session	null
1	Authentication with S1 and Access to D1	Allowed because Authentication scheme is satisfied	Level 2, authentication time 1
21	Access to D2	Allowed	Level 2, authentication time 1
66	Access to D1	Denied due to Application Domain Timeout (based on the parameters configured)	Level 2, authentication time 1
67	Authentication with S1 and Access to D1 and D2	Both Allowed because the Authentication Sceme is satisfied	Level 2, authentication time 67

17.3.2 Example 2: Multiple Authentication Schemes

In previous releases of Access Manager, a session could only have its authentication level reduced in the context of an Oracle Identity Management integration self-service flow (such as forced password reset). In this release, step-down authentication occurs when a session times out as a matter of course--until the user happens to provide new credentials that satisfy a scheme of the same level as the maximum held by the session previously. Otherwise, from the authentication perspective, it is as if the session is new and further step-up is required. Consider this example with two authentication schemes (for step-up and step-down).

• Authentication schemes S1 (Level 2) and S2 (Level 3)

• Application domains D1 and D2

• All resources within each domain are protected with a single authentication policy, and a single authorization policy

• D1 uses S1; D2 uses S2

• Global Session Configuration:

  • Session Life: 240 mins

  • Idle Timeout: 30 mins

  • Appdomain 2 (D2) Timeout: 15 mins (appdomain setting)

When accessing resources from D1, timeout will occur after 30 minutes (global timeout setting); D2 timeout will happen after 15 mins since its timeout value is overridden at the global level. Table 17-6 shows the resulting outcomes.

Table 17-6 Session Outcomes: Multiple Authentication Schemes

Time (Delta)	Action	Access Allowed or Denied	Session Content
0	Access D1 resource (RD1)	Access allowed after successful login	Timeout for D1 will be set to 0+30=30 (30 is default global timeout as D1 has not overriden timeout at the Application Domain level)
1 (implies after 1 minute)	Access D2 resource (RD2)	Access allowed post credential challenge (user will be prompted for credentials since D2 is protected using a higher authentication scheme)	Timeout of D2 will be set to 1+15=16
t>16 and t<30 (say t=20)	Access RD1 and RD2	Allowed access to RD1 because timeout of D1=30. Allowed access to RD2 after providing credentials since timeout of D2=16	The new timeout of D2 is 16
40	Access RD1	Allowed: D1 resource will be allowed since timeout is 50
55	Access RD1 and RD2	Allowed to access both resources after user is successfully challenged for credentials.	Timeout of D1 is now 85 (55+30) Timeout of D2 is now 70 (55+15)

The access order does have an impact on the outcome. For instance, the last D1 access could have been allowed if the user had chosen to first pursue access to the D2 application after credentials had expired. For example:

• Authentication S2 with Access to D2 Allowed: L3 scheme satisfied; resulting level of the now (again) active session same as before. Session Content: Level 3, authentication time 51

• Access to D1 Allowed: Level 3 credentials also sufficient for Level 2-protected access. Session Content: Level 3, authentication time 51.

17.4 Configuring the Server-Side Session Lifecycle

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:

• About Global Session Lifecycle Settings

• About Application-Specific Session Overrides

• Viewing or Modifying Global Session Settings

• Viewing or Modifying Optional Application-Specific Session Overrides

17.4.1 About Global Session Lifecycle Settings

Access Manager session lifecycle settings are defined as part of the Common Settings shared by all OAM Servers. Figure 17-2 shows the lifecycle attributes that you can configure on the Common Settings page.

Figure 17-2 Global Session Details: Common Settings Page

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

Table 17-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:

Oracle Fusion Middleware Performance and Tuning Guide

Table 17-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: "About 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 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.

17.4.2 About Application-Specific Session Overrides

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 17-8 lists application-specific settings that, when specified, override global session settings.

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

For more information, see "Viewing or Modifying Optional Application-Specific Session Overrides".

17.4.3 Viewing or Modifying Global Session Settings

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

See Also:

"About Global Session Lifecycle Settings"

To view or modify global session settings

1. From the Oracle Access Management Console, 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 17-7):

   • Session Lifetime (minutes)

   • Idle Timeout (minutes)

   • Maximum Number of Sessions per User

   • (Management) Maximum Search Results - denotes the number of sessions fetched by default for a session query if the result set is large

   • Database Persistence of Active Sessions Enabled

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 one of the following topics:

   • "Viewing or Modifying Optional Application-Specific Session Overrides"

   • "Managing Active Server-Side Sessions"

17.4.4 Viewing or Modifying Optional Application-Specific Session Overrides

Users with valid Administrator credentials can use the following procedure to modify optional session settings for one or more application domains in a named group.

See Also:

"About Application-Specific Session Overrides"

To view or modify optional application-specific session settings

1. From the Oracle Access Management Console, click Application Domains.

2. Find and open the desired domain.

3. On the Summary tab, enter the following information to create (or add) this domain to the group that uses session overrides (Table 17-8):

   • Idle Timeout

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

5. Proceed to "Managing Active Server-Side Sessions".

17.5 Managing Active Server-Side Sessions

The Oracle Access Management Console 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 Pages

• Managing Active Sessions

17.5.1 About the Session Management Pages

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

Figure 17-3 Common Configuration: Session Management Page

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

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

Table 17-9 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, 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

17.5.2 Managing Active 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.

See Also:

"About the Session Management Pages"

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 Management Console, click Session Management.

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

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 Server-Side Session Operations".

17.6 Verifying Server-Side Session Operations

Use the following procedure to verify your configured session lifecycle operations.

To validate session operations

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.

17.7 Understanding Client-Side Session Management

Client-side (or cookie-based) session management is a light weight session management solution that reduces server-side overhead and provides better scalability. It uses client-side cookies as the persistent mechanism for SSO sessions, making the server stateless. Client-Side session management supports the following features:

• Authentication

• Authorization (excluding session constrains and responses)

• OAM & OIM integration over TAP - excluding session deletion on attribute change (account lock/disable, etc.)

• Step up authentication

• Inactivity time out with single web domain

17.8 Using WLST To Configure Session Management

The following WLST commands can be used to configure for server-side (default) or client-side (cookie-based) session management.

• displaySSOSessionType

• configSSOSessionType

17.8.1 displaySSOSessionType

Online and offline command that allows you to view the session management configuration.

17.8.1.1 Description

Allows you to view the session type configuration.

17.8.1.2 Syntax

displaySSOSessionType(domainHome="<domainHome>") 

Argument	Definition
domainHome	Specifies the location for the Weblogic Server OR Cell Path for WebSphere. This parameter is mandatory for WebSphere. When Offline, a value is mandatory; when online, optional.

17.8.1.3 Example

displaySSOSessionType(domainHome="/oracle/product/OAM/domains/oam_domain")

17.8.2 configSSOSessionType

Online and offline command that allows you to configure session management as COOKIE-BASED or DEFAULT.

17.8.2.1 Description

Configure session management for Access Manager.

17.8.2.2 Syntax

configSSOSessionType(type="<ssoSessionType>",
  cookieDomain="<cookieDomain>",domainHome="<domainHome>")

Argument	Definition
type	Specifies the type of session store. Accepted values are COOKIE_BASED or DEFAULT.
cookieDomain	Specifies the value of the SSO Session Timeout cookie domain.
domainHome	Specifies the location for the Weblogic Server OR Cell Path for WebSphere. This parameter is mandatory for WebSphere. When Offline, a value is mandatory; when online, optional.

17.8.2.3 Examples

configSSOSessionType(type="COOKIE_BASED",cookieDomain-".example.com")

configSSOSessionType(type="COOKIE_BASED",cookieDomain-".example.com",
  domainHome="domainHome1")

configSSOSessionType(type="Default",cookieDomain=".example.com")