PingAM 8.0.0

Session termination

AM manages active sessions, allowing single sign-on when authenticated users attempt to access system resources in AM’s control.

Authenticated sessions are terminated when a configured timeout is reached or when a user performs actions that cause session termination. Session termination effectively logs the user out of all systems protected by AM.

With server-side authenticated sessions, AM terminates sessions in four situations:

  • When a user explicitly logs out.

  • When an administrator monitoring sessions explicitly terminates an authenticated session.

  • When an authenticated session exceeds the maximum time-to-live.

  • When a user is idle for longer than the maximum session idle time.

Under these circumstances, AM responds by removing server-side authenticated sessions from the CTS token store and from AM server memory caches. With the authenticated session no longer present in CTS, AM forces the user to reauthenticate during subsequent attempts to access protected resources.

When a user explicitly logs out of AM, AM also attempts to invalidate the iPlanetDirectoryPro cookie in users' browsers by sending a Set-Cookie header with an invalid session ID and a cookie expiration time that’s in the past. In the case of administrator session termination and session timeout, AM can’t invalidate the iPlanetDirectoryPro cookie until the next time the user accesses AM.

Session termination differs for client-side authenticated sessions. Since client-side authenticated sessions aren’t maintained in the CTS token store, administrators can’t monitor or terminate them. Because AM doesn’t modify the iPlanetDirectoryPro cookie for client-side sessions after authentication, the session idle time isn’t maintained in the cookie. Therefore, AM doesn’t automatically terminate client-side authenticated sessions that have exceeded the idle timeout.

Find information about tracking idle time in PingGateway in AmSessionIdleTimeoutFilter.

As with server-side authenticated sessions, AM attempts to invalidate the iPlanetDirectoryPro cookie from a user’s browser when the user logs out. When the maximum session time is exceeded, AM also attempts to invalidate the iPlanetDirectoryPro cookie in the user’s browser the next time the user accesses AM.

It’s important to understand that AM can’t guarantee cookie invalidation. For example, the HTTP response containing the Set-Cookie header might be lost. This isn’t an issue for server-side sessions, because a logged-out session no longer exists in the CTS token store, and a user who attempts to access AM after previously logging out will be forced to reauthenticate.

However, without the guarantee of cookie invalidation, deployments with client-side sessions can experience issues. For example, a logged-out user could still have an iPlanetDirectoryPro cookie but AM wouldn’t know they had logged out. Therefore, AM supports a feature that takes additional action when users log out of client-side sessions. AM can maintain a list of logged out client-side sessions in a session denylist in the CTS token store. Whenever users attempt to access AM with client-side sessions, AM checks the session denylist to validate that the user has not, in fact, logged out.

Because AM doesn’t modify client-side session cookies after they’re stored in the end user’s browser, and client-side sessions contain the session maximum time-to-live, you must protect them against tampering. Learn more in Client-side session security.

Configure authenticated session timeout settings

Session timeout settings (maximum session time and maximum idle time) can be set at different levels to provide greater control over terminating authenticated sessions.

AM determines which settings to apply to the authenticated session in the following order of precedence:

  1. The session timeout settings for a user.

    Go to Realms > Realm Name > Identities > Username > Services > Session to set user level session timeout values.

    If the Session service isn’t listed, click Add Service and select Session in the list.

  2. The session timeout settings in a node:

    If a tree has multiple nodes that set session timeouts, AM uses the settings associated with the last executed node to determine the timeouts for the resulting authenticated session.

    If an inner tree includes nodes that set session timeouts, AM uses the updated timeouts in the parent tree.

  3. The session timeout settings for an authentication tree.

    Set the maximumSessionTime and maximumIdleTime properties in the tree configuration.

    Session timeout values set on an inner tree are ignored.

    Learn more in Configure authenticated session timeouts in a tree.

  4. The session timeout values set in the realm.

    Enable the Session service in the realm to set realm level session timeout values.

    Learn more in Enable dynamic session attributes for the realm.

  5. The session timeout values set globally for the AM site.

    The default maximum session timeout is 120 minutes and the default maximum idle time is 30 minutes.

    Go to Configure > Sessions > Dynamic Attributes to change the default session timeout values.

    Learn more in Dynamic attributes.

Enable dynamic session attributes for the realm

To configure the session termination settings for a particular realm, enable the Session service:

  1. In the AM admin UI, go to Realms > Realm Name > Services.

  2. Check if the Session service appears in the list of services configured for the realm.

    If it doesn’t, click Add a Service and select Session in the list.

    The Session page appears, showing the Dynamic Attributes tab.

  3. Click Save Changes.

Learn more in Dynamic attributes.

Set maximum session time-to-live

When configuring the maximum session time-to-live (TTL), you must balance security and user experience. Depending on your application, it could be acceptable for your users to log in once a month. Financial applications, for example, tend to expire their sessions in less than an hour.

The longer an authenticated session is valid, the larger the window during which a malicious user could impersonate a user if they were able to hijack a session cookie.

The maximum session time-to-live is 120 minutes by default.

The following steps configure the maximum session time in a realm, but you can also configure it for a user, in a node, in a tree or globally:

  1. In the AM admin UI, go to Realms > Realm Name > Services > Session > Dynamic Attributes.

  2. In the Maximum Session Time field, set a value suitable for your environment.

  3. Save your changes.

If you update the maximum session TTL, consider reviewing the expiry time for OAuth 2.0 JWTs according to your business needs. It may be convenient to set them to the same value, but there are times when these values need to be different.

  1. To update the JWT lifetime for individual OIDC clients:

    1. In the AM admin UI, go to Realms > Realm Name > Applications > OAuth 2.0 > Clients > Client ID > OpenID Connect.

    2. Set OpenID Connect JWT Token Lifetime (seconds) to the same duration as the maximum session TTL (minutes).

      This value overrides the JWT lifetime set for the OAuth 2.0 provider.

  2. To update the JWT lifetime for the OAuth2 Provider service:

    1. In the AM admin UI, go to Realms > Realm Name > Services > OAuth2 Provider > OpenID Connect.

    2. Set OpenID Connect JWT Token Lifetime (seconds) to the same duration as the maximum session TTL (minutes).

Set maximum session idle timeout

Consider a user with a valid authenticated session navigating through pages or making changes to the configuration. If for any reason they leave their desk and their computer remains open, a malicious user could take the opportunity to impersonate them.

Session idle timeout can help mitigate those situations by logging out users after a specified duration of inactivity.

The maximum session idle timeout is 30 minutes by default.

You can only use session idle timeout in realms configured for server-side sessions.

The following steps configure the maximum idle time in a realm, but you can also configure it for a user, in a node, in a tree or globally:

  1. In the AM admin UI, go to Realms > Realm Name > Services > Session > Dynamic Attributes.

  2. On the Maximum Idle Time property, configure a value suitable for your environment.

  3. Save your changes.

Configure client-side session denylisting

Session denylisting makes sure users who have logged out of client-side sessions can’t achieve single sign-on without reauthenticating to AM. Session denylisting doesn’t apply to journey sessions.

  1. Make sure you deployed the Core Token Service (CTS) during AM installation.

    The session denylist is stored in the CTS token store.

  2. Go to Configure > Global Services, click Session, and locate the Client-Side Sessions tab.

  3. Select the Enable Session Denylisting option to enable session denylisting for client-side authenticated sessions.

    When you configure one or more AM realms for client-side sessions, you should enable session denylisting to track session logouts across multiple AM servers.

    Changing the value of this property takes effect immediately.

  4. Configure the Session Denylist Cache Size property.

    AM maintains a cache of logged-out client-side authenticated sessions. The cache size should be approximately equal to the number of logouts expected during the maximum session time.

    Increase the default value of 10,000 if the expected number of logouts during this period is significantly higher. If the session denylist cache is too small, AM reads denylist entries from the CTS token store instead of getting them from cache, which can lead to a small reduction in performance.

    Changing the value of this property takes effect immediately.

  5. Configure the Denylist Poll Interval property.

    AM polls the Core Token service for changes to logged-out sessions if session denylisting is enabled. By default, the polling interval is 10 seconds.

    The longer the polling interval, the more time a malicious user has to connect to other AM servers in a cluster and make use of a stolen session cookie. Shortening the polling interval improves the security for logged out sessions, but could reduce AM performance due to increased network activity.

    Changing the value of this property doesn’t take effect until you restart AM.

  6. Configure the Denylist Purge Delay property.

    When session denylisting is enabled, AM tracks each logged-out session for the maximum session time plus the denylist purge delay. For example, if a session has a maximum time of 120 minutes and the denylist purge delay is one minute, AM tracks the session for 121 minutes. Increase the denylist purge delay if you expect system clock skews in a cluster of AM servers to be greater than one minute. There is no need to increase the denylist purge delay for servers running a clock synchronization protocol, such as Network Time Protocol.

    Changing the value of this property doesn’t take effect until you restart AM.

  7. Click Save Changes.

    Enabling or disabling the session denylist, or altering the cache size, takes effect immediately.

    Changes to any other session denylist properties don’t take effect until you restart AM.

Find detailed information about session service attributes in session configuration.