Session configuration
This page describes how to set the timeout period for a session token and how to enable/disable in-memory token storage.
Session timeout
When a successful authentication occurs, for either an application or a user, a unique token is assigned. Tokens are valid for the period of time specified as the 'Session timeout' attribute.
The session timeout determines how long a session will be considered valid during any period of inactivity. This value is specified in minutes and must be greater than 0.
To specify the session timeout:
- Log in to the Crowd administration console.
- In the upper-right corner, select Administration
. - In the left-hand menu, select Session configuration.
The 'Session config' screen will appear. - Type the new value into the 'Session timeout' field, then select the Update.
Require consistent client IP address
(Available since Crowd 2.5.2.)
Authenticated sessions can be tied to the IP address they were created from. This means that an attempt to use that session from another machine will fail, which will force mobile clients to re-authenticate when their IP address changes.
This setting can be disabled to relax that requirement, so a session can be used from any IP address. Note that changing this setting will invalidate any existing sessions, so you'll be logged out after making this change.
To allow sessions to be used from any IP address:
- Log in to the Crowd Administration Console.
- In the upper-right corner, select Administration .
- In the left-hand menu, select Session configuration.
The 'Session config' screen will appear. - Check or uncheck Require consistent client IP address as required.
- Select Update.
Authentication token storage
Authentication tokens are used to validate application and user sessions. A token is stored for each active session. By default, they're kept in the Crowd database. Storing these tokens in memory can benefit performance, but with one significant drawback, that sessions won't be saved across Crowd restarts. If you restart Crowd, all your users will have to log in again.
In-memory token management isn't available in multi-node (clustered) Crowd environment.
Switching from database to in-memory token management does not require a restart of Crowd; nor will sessions be lost or validations failed. However, if you have a lot of active sessions, and therefore lots of tokens, it can take some time to copy the token information. During this time, validation requests will be queued and Crowd will appear unresponsive to client applications.
As a guide, below are some benchmarks of time taken to switch from one form of token storage to the other. The measurements were taken on a quad-core Mac Pro, using a lightly-loaded PostgreSQL database:
Number of Tokens: | 100 | 500 | 1000 | 5000 | 10000 |
|---|---|---|---|---|---|
Database -> Memory | 0.1s | 0.7s | 1.2s | 4.2s | 8.2s |
Memory -> Database | 1.2s | 4.8s | 9.2s | 45s | 90s |
To switch the token storage location:
- Log in to the Crowd Administration Console.
- In the upper-right corner, select Administration .
- In the left-hand menu, select Session configuration.
The 'Session config' screen will appear. - Next to Authentication token storage, select one of the radio buttons:
- 'Database cache' — This is the default option. Select it to store your tokens in the Crowd database. We recommend this option unless performance problems require in-memory storage.
'Memory cache' — Select this option to store your tokens in memory.
- Select Update.
In-memory cache size
The size of the in-memory token cache is defined in the crowd-webapp/WEB-INF/classes/crowd-ehcache.xml file. The default should be acceptable for most cases. If you require more than 2048 concurrent sessions in memory you may increase the size of the '-hash-cache' caches.
Remember Me settings
Use this setting to define the number of days a user's login is remembered for. You can also turn the Remember Me option off to force the need to provide credentials every time a users wants to log in.
Clear cookies
If for any reasons, like for example security breach, you want to force your users to log in again, select Clear all cookies. This will force all users to log in again once their session expires. The session expiration time is configured in the session timeout setting in the same screen.