1. Administering Oracle Access Management
  2. Managing Access Manager Settings and Agents
  3. Maintaining Access Manager Sessions

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

The following topics describe concepts and procedures for Access Manager sessions:

16.1 Introducing Access Manager Session Management

With this 12.2.1.3.0 release of Oracle Access Management, Access Manager sessions are managed on the server-side backed by a database.

OAM 12.2.1.3.0 server supports database-backed server-side session manager to synchronize session state across multiple nodes of the OAM server cluster. The session is persisted in the AM_SESSION table.

Session manager handles data for an active session uniquely identified by the OAM Server. The lifecycle of the session is managed at the server side by storing a session-id at the client side. The session-id uniquely identifies a user session stored at the OAM 12c server and is used in subsequent requests to fetch the session from server session store and identify the state of client.

The OAM server transforms the session into a token (session token) and sends it in the response. The token contains information to query the database on subsequent access to reconstruct the session at a later time. On subsequent requests, the token is retrieved from the request to identify and fetch the session to get all the details of logged-in user.

As the server-side sessions are backed by a database, it is required that the database is always available so that the sessions being fetched from the database do not fail during Access operations. OAM 12.2.1.3.0 provides Tokenized Session Management that supports access operations when the database is not available.

Database Unavailability Scenarios

In OAM 12.2.1.3.0, only the following scenarios are taken as database-unavailability by the Session Manager.

  • Database is down

  • Connection pool exhaustion, due to which there are no free connections to connect to the database

  • Network latency issues, due to which the database connectivity, and latency of the database operations are degraded

Note:

Database must be available during startup of admin server, policy manager and OAM runtime servers of OAM domain.

The Tokenized Session supports the following features when the database is unavailable:

Table 16-1 Features Supported when the Database is Unavailable

Features and Components Supported when the DB is Unavailable Scenarios
WebGate 11g Authentication, Authorization (without session constraints) & SSO flows
Webgate 12c Authentication, Authorization (without session constraints) & SSO flows
Java ASDK ASDK Operations

Note:

ASDK operations related to session are not supported.
OAuth Non-session link scenarios

The Tokenized Session Management does not support the following features when the database is unavailable.

Table 16-2 Features Not Supported when the Database is Unavailable

Features and Components Not Supported (as they rely on server-side sessions) when the DB is Unavailable Description
Java ASDK DB availability is mandatory for ASDK session operations to work
Session Responses DB availability is mandatory for session responses to work
Session Snipe DB availability mandatory. If DB is not available after session snipe, behavior of authorizations from the already established sessions are defined based on the session policy
Remote Session Kill DB availability mandatory
OAuth MDC Session Link DB availability mandatory due to OAuth Token and OAM_ID sync issues in the flow.
DCC/NAP Tunneling Not supported / Not certified
LDAP Prefetch LDAP Prefetch will not work when DB is down. Additional LDAP queries might be needed during authorization to evaluate identity authz contstaints.
oamconsole Admin operations are not supported when DB is down

See Also:

Polling Interval for System and Policy Configuration

SQL Queries to List Sessions and Plugins from Database

16.2 Understanding Server-Side Session Management

OAM 12.2.1.3.0 server supports database-backed server-side session manager to synchronize session state across multiple nodes of the OAM server cluster

The following topics provide an overview of server-side session management:

16.2.1 About Securing Access Manager Sessions

Session security begins with a secure installation.

For installation details see the Preparing to Install and Configure Oracle Access Management in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

See Also:

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

The HTTPS protocol 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.

  • Database Encryption

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

16.2.2 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

    Note:

    Idle Timeout can also be implemented as application-specific settings, as described later.

  • Maximum number of Sessions

See Global Session Lifecycle Settings.

Table 16-3 lists the Session lifecycle states.

Table 16-3 Session Lifecycle States

State Description

Active

Newly-created sessions are active. A session is created when the user is authenticated by Access Manager.

The session remains active until Access Manager determines that the session must transition into one of the other states in this table.

Note: Administrators can delete only active sessions.

Idle

An active session becomes idle when the user does not access Access Manager-protected content for the period defined by an Administrator.

When an active session becomes idle, the user must re-authenticate to proceed. When re-authentication is successful, the session returns to the Active state; session attribute values are preserved through this process.

Expired

An active session expires when the duration of the session exceeds the defined lifetime. An expired session is completely inaccessible and eligible for deletion. When an active session expires, the user must re-authenticate to proceed.

When re-authentication is successful, a new session is created; however, session attribute values are not preserved (as they are for Idle states).

See the following topics for more information about:

16.2.2.1 Global Session Enforcement Checks for State Changes

Each Access Manager session holds two time attributes and applicable values.

Following are the two time attributes:

  • Session creation time

  • Last access time

The values of these attributes are compared for session enforcement as described in "Table 16-4".

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

16.2.2.2 Access Manager Session Removal

A session can be removed by three actions: expiration, user logout, and termination.

Session removal actions are described in Table 16-5.

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

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

In a step-up flow, a user authenticates to access protected content and later in the same session, the user requests other, more sensitive content and is required to authenticate again to access it at a more stringent level. In a step-up flow, multiple authentications always occur in order of the increasing authentication level. Each session holds the Authentication Level attribute for step-up authentication enforcement.

If the re-Authentication Level is less than that previously contained in the session, the user has completed a step-down process. Upon successful re-authentication, the session is restored to the Active state with an Authentication Level that is equal to the lower level of the authentication scheme used. If the user later attempts to access content that is protected at a higher level, step-up authentication occurs.

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

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

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

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

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

16.3.2 Example 2: Multiple Authentication Schemes

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 16-8 shows the resulting outcomes.

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

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

16.4.1 Global Session Lifecycle Settings

Access Manager session lifecycle settings are defined as part of the Common Settings shared by all OAM Servers.

Figure 16-1 shows the lifecycle attributes that you can configure on the Common Settings page.

Figure 16-1 Global Session Details: Common Settings Page

Description of Figure 16-1 follows
Description of "Figure 16-1 Global Session Details: Common Settings Page"

Table 16-9 describes the global session lifecycle settings and their defaults. Sessions can operate in a disconnected mode. 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:

Tuning Performance

Table 16-9 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:

  • The change is effective after the subsequent poll for configuration change (based on the interval configured in oracle.oam.EntityRefreshIntervalMillis. Default value is 30 seconds.)

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

  • The change is effective after the subsequent poll for configuration change (based on the interval configured in oracle.oam.EntityRefreshIntervalMillis. Default value is 30 seconds.)

  • 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: "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:

  • During authentication, if the database is not available, the Maximum Number of Sessions per User enforcement does not work.

  • 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 Tuning Performance

(Management) Maximum Search Results

Maximum number of sessions fetched by default for a session query if the result set is large.

16.4.2 Polling Interval for System and Policy Configuration

OAM system configuration store and policy stores are polled for changes with the following polling intervals.

In OAM 12.2.1.3.0, policy and system configurations are synchronized over a pull-based model. This is driven by the individual OAM server nodes polling for changes in corresponding configurations.

Table 16-10 Default Polling Interval

Configurations Default Polling Interval (in milliseconds and seconds)
System Configuration Store every 30000 milliseconds (30 seconds)
Policy Store every 30000 milliseconds (30 seconds)
OAM Config MBean reloads changes from configuration store every 30000 milliseconds (30 seconds)

Polling interval can be configured using the oracle.oam.EntityRefreshIntervalMillis system property for all the configurations listed inTable 16-10.

For example, to change the policy store polling interval to 60 seconds, set the following:

-D oracle.oam.EntityRefreshIntervalMillis=60000

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

Table 16-11 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

Note:

  • The change is effective after the subsequent poll for configuration change (based on the interval configured in oracle.oam.EntityRefreshIntervalMillis. Default value is 30 seconds.)

  • When the app domain timeout value is less than the global session timeout value and it is more restrictive, the app domain idle timeout overrides the global session idle timeout. When it is greater than global session timeout, OAM session timeout is based on the Global Settings value.

  • When the DB is down, the app domain session idle timeout does not override the global session idle timeout.

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

16.4.4 Viewing or Modifying Global Session Settings

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

For more information, see "Global Session Lifecycle Settings"

  1. In the Oracle Access Management Console, click Configuration at the top of the window.
  2. In the Configuration console, select Common Settings from the View menu in the Settings section.
  3. On the Common Settings page, expand the Session section.
  4. Click the arrow keys beside each list to increase or decrease session lifecycle settings as needed (Table 16-9):

    • 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

  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:

16.4.5 Viewing or Modifying Optional Application-Specific Session Overrides

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

For more information, see "Application-Specific Session Overrides".

  1. In the Oracle Access Management Console, click Application Security at the top of the window.
  2. In the Access Manager section, click Application Domains.
  3. Find and open the desired domain.
  4. On the Summary tab, enter the following information to create (or add) this domain to the group that uses session overrides (Table 16-11):

    • Idle Timeout

  5. Click Apply to submit the changes (or close the page without applying changes).
  6. Proceed to "Managing Active Server-Side Sessions".

16.5 Managing Active Server-Side Sessions

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. The Oracle Access Management ConsoleIn 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:

16.5.1 Session Management Controls

The Session Management page is accessible from the Configuration section of the Oracle Access Management Console.

Figure 16-2 illustrates the Session Management page. Additional details follow the figure.

Figure 16-2 Common Configuration: Session Management Page

Description of Figure 16-2 follows
Description of "Figure 16-2 Common Configuration: Session Management Page"

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

Table 16-12 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

Drop down menu that lists any search criteria saved previously for reuse. The list of searches is made available whenever you save search criteria.

The drop down menu also has a Personalize ... option in addition to the saved searches. If you choose Personalize, you can change the behavior of the saved search criteria by making new choices such as Set as Default or Run Automatically.

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.

User ID

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. A drop down menu includes options like Starts With, Equals, Contains and the like to assist in 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.

Note:

The search query is ANDed together and the results are returned.

Reset

Click this button to clear the form of all criteria.

Add Fields

Displays a drop down menu from which you can select different options to add to your search form. This can include Client IP Address, ID Store, Impersonating and other options.

  1. Click the Add Fields button.

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

Reorder

Displays a pop-up dialog allowing you to reorder the search fields.

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 (red X) 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 Detach 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

Note:

  • The option isunset against a field selected in the search criteria, returns sessions, for which the corresponding field value has not been set. For example, if your search criteria is Client IP Address with option unset, the search returns the sessions, for which the Client IP address is not set.

  • The option isnull against a field selected in the search criteria, returns sessions, for which the corresponding field value is set as null.

    For example, if your search criteria is User Id with option isnull, the search returns the sessions with UserID value equal to null.

16.5.2 Locating and Managing Active Sessions

Users with valid Administrator credentials can 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:

"Session Management Controls"

Skip any steps that do not apply to your requirements. The OAM Server must be running.

  1. In the Oracle Access Management Console, click Application Security at the top of the window.

  2. In the Application Security console, click Session Management.

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

  3. Add Fields: From the Add Fields list, choose the desired field name (Table 16-12).

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

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

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

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

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

  9. Close the Session Management page when you finish.

  10. Proceed to "Validating Server-Side Session Operations".

16.6 Validating Server-Side Session Operations

You can verify your configured session lifecycle 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 "Locating and 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 "Locating and 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 am_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 am_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.

16.7 Using REST APIs for CRUD Operations on a Session

Session REST APIs manage sessions within a data center. Generally, CRUD operations on a session are performed in the session layer. Without adding new APIs or capabilities to the session layer, the Session REST APIs help Create, Read, Update, and Delete sessions. Administrators with Session REST API User role can use Session REST API for CRUD operations on a session.

Following are the tasks that the Administrator can perform using the Session REST APIs:

16.7.1 Searching Sessions Using Session REST API

Administrators with Session REST API User role can search for user sessions using searchSessions API.

Use the userId to search for sessions pertaining to a particular user. To search for a particular session, use the sessionId. If you have the clientIp, you can search for all the sessions coming from that client address.

Note:

Searching a session lists out only 28 sessions per query and the displayed search results are not paginated.
  1. Provide userId to search for the sessions of a particular user.
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X POST -d '{"userId":"user2"}' http://<HOST>:<PORT>/oam/services/rest/access/api/v1/sessions

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>2</totalRecords>
<sessions>
<sessionData>
<sessionId>53f96ca1-e65a-47ee-a758-a1cebb63f4b3|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:56:19.000-07:00</createTime>
<updateTime>2017-05-31T13:56:19.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:19.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>a3d62e11-3f22-4336-b76c-e8f8cbd46306|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:55:43.000-07:00</createTime>
<updateTime>2017-05-31T13:55:43.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:55:43.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>
  2. Provide clientIp to search for the sessions of a particular client address.
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X POST -d '{"clientIp":"1.2.3.4"}' http://<HOST>:<PORT>/oam/services/rest/access/api/v1/sessions

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>4</totalRecords>
<sessions>
<sessionData>
<sessionId>a9cacf25-18cc-4d72-9237-e32394fa294e|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=</sessionId>
<createTime>2017-05-31T13:57:32.000-07:00</createTime>
<updateTime>2017-05-31T13:57:32.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:32.000-07:00</lastAccessTime>
<userId>user5</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>32de23f1-9f53-47e7-b4d5-9d0376187241|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:35.000-07:00</createTime>
<updateTime>2017-05-31T13:56:35.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:35.000-07:00</lastAccessTime>
<userId>user3</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>a3d62e11-3f22-4336-b76c-e8f8cbd46306|L+h1SktCgMtjnOnmIWL+gnpIstrT9hGuPD0beqGK5Cc=</sessionId>
<createTime>2017-05-31T13:55:43.000-07:00</createTime>
<updateTime>2017-05-31T13:55:43.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:55:43.000-07:00</lastAccessTime>
<userId>user2</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>c639fb4d-f467-4da3-88c8-0e6754d809a7|hUNJ4YlF30b5ycVlEq7iZ8LwFa8i9G5QhmKdkr3TizU=</sessionId>
<createTime>2017-05-31T13:57:17.000-07:00</createTime>
<updateTime>2017-05-31T13:57:17.000-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:17.000-07:00</lastAccessTime>
<userId>user4</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

16.7.2 Deleting a Session Using Session REST API

The Administrator with Session REST API User role can delete one or more user sessions using deleteSession REST API.

  1. To delete a single session, use sessionId in the deleteSession REST API as follows:
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X "DELETE" “http://<HOST>:<PORT>/oam/services/rest/access/api/v1/session?sessionId= 3b844e4d-9019-4928-9dca-3ba2ebbf475d%7CU90idWYSK4hXcdo6LlVD2%2BJuHBLvbGtCbbhlfmoDvMA%3D”

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>1</totalRecords>
<sessions>
<sessionData>
<sessionId>3b844e4d-9019-4928-9dca-3ba2ebbf475d|U90idWYSK4hXcdo6LlVD2+JuHBLvbGtCbbhlfmoDvMA=</sessionId>
<createTime>2017-05-31T13:57:59.545-07:00</createTime>
<updateTime>2017-05-31T13:57:59.545-07:00</updateTime>
<lastAccessTime>2017-05-31T13:57:59.545-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:57:59.545-07:00</expiryTime>
<userId>user5</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

    Note:

    The sessionId is encoded as it contains special characters.
  2. When a user is terminated, the Administrator can search for all the user's sessions using the userId (or optionally using id-store) and delete all the sessions as follows:
    
Sample request
curl -H "Content-Type: application/json" -H "Authorization: Basic <Base64 encoded auth header>" -X "DELETE" "http://<HOST>:<PORT>/oam/services/rest/access/api/v1/session?userId=user3"

Sample response
<?xml version="1.0" encoding="UTF-8"?>
<SessionResults>
<totalRecords>2</totalRecords>
<sessions>
<sessionData>
<sessionId>32de23f1-9f53-47e7-b4d5-9d0376187241|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:35.426-07:00</createTime>
<updateTime>2017-05-31T13:56:35.426-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:35.426-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:56:35.426-07:00</expiryTime>
<userId>user3</userId>
<clientIp>1.2.3.4</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
<sessionData>
<sessionId>3e8fd79e-03b8-4c90-bf4d-964119460a0a|c+4quN74tM7P6qvbYVqa6BQOg3RYHDsFT3PzPajvEzM=</sessionId>
<createTime>2017-05-31T13:56:52.918-07:00</createTime>
<updateTime>2017-05-31T13:56:52.918-07:00</updateTime>
<lastAccessTime>2017-05-31T13:56:52.918-07:00</lastAccessTime>
<expiryTime>2017-05-31T21:56:52.918-07:00</expiryTime>
<userId>user3</userId>
<clientIp>5.6.7.8</clientIp>
<idStoreName>UserIdentityStore1</idStoreName>
<isImpersonating>false</isImpersonating>
</sessionData>
</sessions>
</SessionResults>

    Note:

    The Administrator can use searchSessions API along with the clientIP parameter to list all the sessions and delete sessions from a specific client address.

16.7.3 Assigning a Delegated Administrator

To the specified users who are defined in LDAP, grant 'Session-REST API User' role before adding them to the group of administrators managing user sessions.

Only a weblog administrator or a user with Session-REST API User role can perform Session REST API functions on OAM runtime Sever. Through the delegated Admin page, from the /oamconsole, add users and assign user roles to the specific users.