Understanding Session Termination
AM manages active sessions, allowing single sign-on when authenticated users attempt to access system resources in AM's control.
AM ensures that user sessions are terminated when a configured timeout is reached, or when AM users perform actions that cause session termination. Session termination effectively logs the user out of all systems protected by AM.
With CTS-based sessions, AM terminates sessions in four situations:
When a user explicitly logs out.
When an administrator monitoring sessions explicitly terminates a session.
When a 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 CTS-based sessions from the CTS token store and from AM server memory caches. With the user's session no longer present in CTS, AM forces the user to reauthenticate during subsequent attempts to access resources protected by AM.
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 is in the past. In the case of administrator session termination and session timeout, AM cannot invalidate the iPlanetDirectoryPro cookie until the next time the user accesses AM.
Session termination differs for client-based sessions. Since client-based sessions are not maintained in the CTS token store, administrators cannot monitor or terminate them. Because AM does not modify the iPlanetDirectoryPro cookie for client-based sessions after authentication, the session idle time is not maintained in the cookie. Therefore, AM does not automatically terminate client-based sessions that have exceeded the idle timeout.
As with CTS-based 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 is important to understand that AM cannot guarantee cookie invalidation. For example, the HTTP response containing the Set-Cookie header might be lost. This is not an issue for CTS-based 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, the lack of a guarantee of cookie invalidation is an issue for deployments with client-based sessions. It could be possible for a logged out user to have an iPlanetDirectoryPro cookie. AM could not determine that the user previously logged out. Therefore, AM supports a feature that takes additional action when users log out of client-based sessions. AM can maintain a list of logged out client-based sessions in a session blacklist in the CTS token store. Whenever users attempt to access AM with client-based sessions, AM checks the session blacklist to validate that the user has not, in fact, logged out.
Since AM does not modify client-based session cookies once they are stored in the end user's browser, and client-based sessions contain, among others, the session maximum time-to-live, it is imperative to protected them against tampering. See "Configuring Client-Based Session Security" for more information.
Configuring Maximum Session Time-to-Live
When configuring the maximum session time-to-live, you must balance security and user experience. Depending on your application, it may 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 a 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.
In the AM console, go to Realms > Realm Name > Services > Session > Dynamic Attributes.
Note that you can also change maximum session time settings globally for the AM site by navigating to Configure > Sessions > Dynamic Attributes.
On the Maximum Session Time property, configure a value suitable for your environment.
Save your changes.
Configuring CTS-Based Session Idle Timeout
Consider a user with a valid 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. Session idle timeout can only be used in realms configured for CTS-based sessions.
In the AM console, go to Realms > Realm Name > Services > Session > Dynamic Attributes.
Note that you can also change idle timeout settings globally for the AM site by navigating to Configure > Sessions > Dynamic Attributes.
On the Maximum Time Idle property, configure a value suitable for your environment.
Save your changes.
Configuring Client-Based Session Blacklisting
Session blacklisting ensures that users who have logged out of client-based sessions cannot achieve single sign-on without reauthenticating to AM. Session blacklisting does not apply to authentication sessions.
Make sure that you deployed the Core Token Service during AM installation. The session blacklist is stored in the Core Token Service's token store.
Navigate to Configure > Global Services, click Session, and then locate the Client-based Sessions tab.
Select the Enable Session Blacklisting option to enable session blacklisting for client-based sessions. When you configure one or more AM realms for client-based sessions, you should enable session blacklisting in order to track session logouts across multiple AM servers.
Changing the value of this property takes effect immediately.
(Optional) Configure the Session Blacklist Cache Size property.
AM maintains a cache of logged out client-based sessions. The cache size should be around the number of logouts expected in the maximum session time. Change the default value of 10,000 when the expected number of logouts during the maximum session time is an order of magnitude greater than 10,000. An underconfigured session blacklist cache causes AM to read blacklist entries from the Core Token Service store instead of obtaining them from cache, which results in a small performance degradation.
Changing the value of this property takes effect immediately.
Configure the Blacklist Poll Interval property.
AM polls the Core Token Service for changes to logged out sessions if session blacklisting is enabled. By default, the polling interval is 60 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 might incur a minimal decrease in overall AM performance due to increased network activity.
Changing the value of this property does not take effect until you restart AM.
Configure the Blacklist Purge Delay property.
When session blacklisting is enabled, AM tracks each logged out session for the maximum session time plus the blacklist purge delay. For example, if a session has a maximum time of 120 minutes and the blacklist purge delay is one minute, then AM tracks the session for 121 minutes. Increase the blacklist 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 blacklist purge delay for servers running a clock synchronization protocol, such as Network Time Protocol.
Changing the value of this property does not take effect until you restart AM.
Click Save Changes.
Important
Enabling or disabling the session blacklist, or altering the cache size, takes effect immediately.
Changes to any other session blacklist properties do not take effect until you restart AM.
For detailed information about Session Service configuration attributes, see the entries for "Session".