Chapter 13. User Session Management
When a user logs into a realm, Red Hat Single Sign-On maintains a user session for them and remembers each and every client they have visited within the session. There are a lot of administrative functions that realm admins can perform on these user sessions. They can view login stats for the entire realm and dive down into each client to see who is logged in and where. Admins can logout a user or set of users from the Admin Console. They can revoke tokens and set up all the token and session timeouts there too.
13.1. Administering Sessions
If you go to the Sessions left menu item you can see a top level view of the number of sessions that are currently active in the realm.
Sessions
A list of clients is given and how many active sessions there currently are for that client. You can also logout all users in the realm by clicking the Logout all button on the right side of this list.
13.1.1. Logout All Limitations
Any SSO cookies set will now be invalid and clients that request authentication in active browser sessions will now have to re-login. Only certain clients are notified of this logout event, specifically clients that are using the Red Hat Single Sign-On OIDC client adapter. Other client types (i.e. SAML) will not receive a backchannel logout request.
It is important to note that any outstanding access tokens are not revoked by clicking Logout all. They have to expire naturally. You have to push a revocation policy out to clients, but that also only works with clients using the Red Hat Single Sign-On OIDC client adapter.
13.1.2. Application Drilldown
On the Sessions page, you can also drill down to each client. This will bring you to the Sessions tab of that client. Clicking on the Show Sessions button there allows you to see which users are logged into that application.
Application Sessions
13.1.3. User Drilldown
If you go to the Sessions tab of an individual user, you can also view the session information.
User Sessions
13.2. Revocation Policies
If your system is compromised you will want a way to revoke all sessions and access tokens that have been handed out. You can do this by going to the Revocation tab of the Sessions screen.
Revocation
You can only set a time-based revocation policy. The console allows you to specify a time and date where any session or token issued before that time and date is invalid. The Set to now will set the policy to the current time and date. The Push button will push this revocation policy to any registered OIDC client that has the Red Hat Single Sign-On OIDC client adapter installed.
13.3. Session and Token Timeouts
Red Hat Single Sign-On gives you fine grain control of session, cookie, and token timeouts. This is all done on the Tokens tab in the Realm Settings left menu item.
Tokens Tab
Let’s walk through each of the items on this page.
| Configuration | Description |
|---|---|
| Revoke Refresh Token | For OIDC clients that are doing the refresh token flow, this flag, if on, will revoke that refresh token and issue another with the request that the client has to use. This basically means that refresh tokens have a one time use. |
| SSO Session Idle | Also pertains to OIDC clients. If the user is not active for longer than this timeout, the user session will be invalidated. How is idle time checked? A client requesting authentication will bump the idle timeout. Refresh token requests will also bump the idle timeout. |
| SSO Session Max | Maximum time before a user session is expired and invalidated. This is a hard number and time. It controls the maximum time a user session can remain active, regardless of activity. |
| Offline Session Idle | For offline access, this is the time the session is allowed to remain idle before the offline token is revoked. |
| Access Token Lifespan | When an OIDC access token is created, this value affects the expiration. |
| Access Token Lifespan For Implicit Flow | With the Implicit Flow no refresh token is provided. For this reason there’s a separate timeout for access tokens created with the Implicit Flow. |
| Client login timeout | This is the maximum time that a client has to finish the Authorization Code Flow in OIDC. |
| Login timeout | Total time a login must take. If authentication takes longer than this time then the user will have to start the authentication process over. |
| Login action timeout | Maximum time a user can spend on any one page in the authentication process. |
| User-Initiated Action Lifespan | Maximum time before an action permit sent by a user (e.g. forgot password e-mail) is expired. This value is recommended to be short because it is expected that the user would react to self-created action quickly. |
| Default Admin-Initiated Action Lifespan | Maximum time before an action permit sent to a user by an admin is expired. This value is recommended to be long to allow admins send e-mails for users that are currently offline. The default timeout can be overridden right before issuing the token. |
| Override User-Initiated Action Lifespan | Permits the possibility of having independent timeouts per operation (e.g. e-mail verification, forgot password, user actions and Identity Provider E-mail Verification). This field is non mandatory and if nothing is specified it defaults to the value configured at User-Initiated Action Lifespan. |
13.4. Offline Access
Offline access is a feature described in OpenID Connect specification . The idea is that during login, your client application will request an Offline token instead of a classic Refresh token. The application can save this offline token in a database or on disk and can use it later even if user is logged out. This is useful if your application needs to do some "offline" actions on behalf of user even when the user is not online. An example is a periodic backup of some data every night.
Your application is responsible for persisting the offline token in some storage (usually a database) and then using it to manually retrieve new access token from Red Hat Single Sign-On server.
The difference between a classic Refresh token and an Offline token is, that an offline token will never expire and is not subject of SSO Session Idle timeout . The offline token is valid even after a user logout or server restart. However by default you do need to use the offline token for a refresh token action at least once per 30 days (this value, Offline Session Idle timeout, can be changed in the administration console in the Tokens tab under Realm Settings). Also if you enable the option Revoke refresh tokens, then each offline token can be used just once. So after refresh, you always need to store the new offline token from refresh response into your DB instead of the previous one.
Users can view and revoke offline tokens that have been granted by them in the User Account Service. The admin user can revoke offline tokens for individual users in admin console in the Consents tab of a particular user. The admin can also view all the offline tokens issued in the Offline Access tab of each client. Offline tokens can also be revoked by setting a revocation policy.
To be able to issue an offline token, users need to have the role mapping for the realm-level role offline_access. Clients also need to have that role in their scope.
The client can request an offline token by adding the parameter scope=offline_access when sending authorization request to Red Hat Single Sign-On. The Red Hat Single Sign-On OIDC client adapter automatically adds this parameter when you use it to access secured URL of your application (i.e. http://localhost:8080/customer-portal/secured?scope=offline_access). The Direct Access Grant and Service Accounts also support offline tokens if you include scope=offline_access in the body of the authentication request.
