libre.sh/keycloak-scim
4
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

Improve documentation for user session limits (#1662)

Browse source 
Closes #1661


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
This commit is contained in:
Marek Posolda 2022-09-02 08:38:23 +02:00 committed by GitHub
parent 28e907a3fa
commit 2be5bf1000
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 11 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
server_admin/keycloak-images/authentication-user-session-limits.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
server_admin/rhsso-images/authentication-user-session-limits.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

15
server_admin/topics/authentication/flows.adoc
View file

@ -415,16 +415,23 @@ To add session limits to a flow, perform the following steps.
. Click *Required* for the *User Session Count Limiter* authentication type to set its requirement to required. . Click *Required* for the *User Session Count Limiter* authentication type to set its requirement to required.
. Click *⚙️* (gear icon) for the *User Session Count Limiter*. . Click *⚙️* (gear icon) for the *User Session Count Limiter*.
. Enter an alias for this config. . Enter an alias for this config.
. Enter the required maximum number of sessions a user can have in this realm. If a value of 0 is used, this check is disabled. . Enter the required maximum number of sessions that a user can have in this realm. For example, if 2 is the value, 2 SSO sessions is the maximum that each user can have in this realm. If 0 is the value, this check is disabled.
. Enter the required maximum number of sessions a user can have for the client. If a value of 0 is used, this check is disabled. . Enter the required maximum number of sessions a user can have for the client. For example, if 2 is the value, then 2 SSO sessions is the maximum in this realm for each client. So when a user is trying to authenticate to client `foo`, but that user has already authenticated in 2 SSO sessions to client `foo`, either the authentication will be denied or an existing sessions will be killed based on the behavior configured. If a value of 0 is used, this check is disabled.
If both session limits and client session limits are enabled, it makes sense to have client session limits to be always lower than session limits. The limit per client can never exceed the limit of all SSO sessions of this user.
. Select the behavior that is required when the user tries to create a session after the limit is reached. Available bahaviors are: . Select the behavior that is required when the user tries to create a session after the limit is reached. Available bahaviors are:
Deny new session - when a new session is requested and the session limit is reached, no new sessions can be created. - *Deny new session* - when a new session is requested and the session limit is reached, no new sessions can be created.
Terminate oldest session - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created. - *Terminate oldest session* - when a new session is requested and the session limit has been reached, the oldest session will be removed and the new session created.
. Optionally, add a custom error message to be displayed when the limit is reached. . Optionally, add a custom error message to be displayed when the limit is reached.
Note that the user session limits should be added to your bound *Browser flow*, *Direct grant flow*, *Reset credentials* and also to any *Post broker login flow*. Note that the user session limits should be added to your bound *Browser flow*, *Direct grant flow*, *Reset credentials* and also to any *Post broker login flow*.
The authenticator should be added at the point when the user is already known during authentication (usually at the end of the authentication flow) and should be typically REQUIRED. Note that it is not possible to have
ALTERNATIVE and REQUIRED executions at the same level. For example for the default browser flow, it may be necessary to wrap the existing flow as a REQUIRED level-1 subflow and
add `User Session Count Limiter` to the same level as this new subflow. Example of such flow is below.
image:{project_images}/authentication-user-session-limits.png[Authentication User Session Limits Flow]
Currently, the administrator is responsible for maintaining consistency between the different configurations. Currently, the administrator is responsible for maintaining consistency between the different configurations.
Note also that the user session limit feature is not available for CIBA. Note also that the user session limit feature is not available for CIBA.