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.
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
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.
13.1.3. User Drilldown
If you go to the
Sessions tab of an individual user, you can also view the session information.
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
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.
Let’s walk through each of the items on this page.
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.
Offline Session Max Limited
For offline access, if this flag is on, Offline Session Max is enabled to control the maximum time the offline token can remain active, regardless of activity.
Offline Session Max
For offline access, this is the maximum time before the corresponding offline token is revoked. This is a hard number and time. It controls the maximum time the offline token can remain active, regardless of activity.
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.
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 by default and is not subject of
SSO Session Idle timeout and
SSO Session Max lifespan . 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). Moreover, if you enable the option
Offline Session Max Limited, then the offline token expires after 60 days regardless of using the offline token for a refresh token action (this value,
Offline Session Max lifespan, can also 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. Finally, the client needs to have an
offline_access client scope added as an
Optional client scope to it, which is done by default.
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.