Clarified "activity" refers to "user activity."
This commit is contained in:
Andy Munro
Stian Thorgersen
parent
9c51a6d394
commit
b285784448
6 changed files with 23 additions and 23 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 186 KiB After Width: | Height: | Size: 117 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 172 KiB After Width: | Height: | Size: 117 KiB |
|
|
@ -4,7 +4,7 @@
|
|||
When a user logs into a realm, {project_name} 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
|
||||
into each client to see who is logged in and where. Admins can logout a user or a set of users from the Admin Console. They
|
||||
can revoke tokens and set up all the token and session timeouts there too.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@ If you go to the `Sessions` left menu item you can see a top level view of the n
|
|||
.Sessions
|
||||
image:{project_images}/sessions.png[]
|
||||
|
||||
A list of clients is given and how many active sessions there currently are for that client. You can also logout all
|
||||
A list of clients is given and how many active sessions there currently are for that client. You can also log out all
|
||||
users in the realm by clicking the `Logout all` button on the right side of this list.
|
||||
|
||||
==== Logout All Limitations
|
||||
==== Limitations of the `Logout all` Operation
|
||||
|
||||
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 {project_name}
|
||||
OIDC client adapter. Other client types (i.e. SAML) will not receive a backchannel logout request.
|
||||
OIDC client adapter. Other client types, such as 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, revocation policy>> out to
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ The application can save this offline token in a database or on disk and can use
|
|||
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 {project_name} server.
|
||||
Your application is responsible for persisting the offline token in some storage (usually a database) and then using it to retrieve new access token from {project_name} 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 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 the `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`, can also be changed in the administration console in the Tokens tab under Realm Settings).
|
||||
|
|
|
|||
|
|
@ -13,38 +13,38 @@ Let's walk through each of the items on this page.
|
|||
|===
|
||||
|Configuration|Description
|
||||
|
||||
|Default Signature Algorithm
|
||||
|The default algorithm that is used to assign tokens for this realm.
|
||||
|
||||
|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.
|
||||
|For OIDC clients that are doing the refresh token flow, this flag, if on, will revoke that refresh token and issue another token with the request that the client has to use. The result is that each refresh token is used only once.
|
||||
|
||||
|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.
|
||||
There is a small window of time that is always added to the idle timeout before the session is actually invalidated (See note below).
|
||||
|Also pertains to OIDC clients. If the user is not active for longer than this timeout, the user session will be invalidated. The idle timeout is reset by a client requesting authentication or by a refresh token request.
|
||||
There is a small window of time that is always added to the idle timeout before the session invalidation takes effect. See the note below.
|
||||
|
||||
|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.
|
||||
|Maximum time before a user session is expired and invalidated. This option controls the maximum time that a user session can remain active, regardless of user activity.
|
||||
|
||||
|SSO Session Idle Remember Me
|
||||
|Same as the standard SSO Session Idle configuration but specific to logins with remember me enabled. It allows for the specification of longer
|
||||
session idle timeouts when remember me is selected during the login process. It is an optional configuration and if not set to a value
|
||||
bigger than 0 it uses the same idle timeout set in the SSO Session Idle configuration.
|
||||
|Same as the standard SSO Session Idle configuration but specific to logins with Remember Me enabled. It allows for the specification of longer
|
||||
session idle timeouts when Remember Me is selected during the login process. It is an optional configuration and if not set to a value
|
||||
greater than 0 it uses the same idle timeout as set in the SSO Session Idle configuration.
|
||||
|
||||
|SSO Session Max Remember Me
|
||||
|Same as the standard SSO Session Max but specific to logins with remember me enabled. It allows for the specification of longer lived
|
||||
sessions when remember me is selected during the login process. It is an optional configuration and if not set to a value bigger than 0
|
||||
it uses the same session lifespan set in the SSO Session Max configuration.
|
||||
|Same as the standard SSO Session Max but specific to logins with Remember Me enabled. It allows for the specification of longer lived
|
||||
sessions when Remember Me is selected during the login process. It is an optional configuration and if not set to a value greater than 0
|
||||
it uses the same session lifespan as set in the SSO Session Max configuration.
|
||||
|
||||
|Offline Session Idle
|
||||
|For <<_offline-access, offline access>>, this is the time the session is allowed to remain idle before the offline token is revoked.
|
||||
There is a small window of time that is always added to the idle timeout before the session is actually invalidated (See note below).
|
||||
There is a small window of time that is always added to the idle timeout before the session invalidation takes effect. See the note below.
|
||||
|
||||
|Offline Session Max Limited
|
||||
|For <<_offline-access, 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.
|
||||
|For <<_offline-access, 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 user activity.
|
||||
|
||||
|Offline Session Max
|
||||
|For <<_offline-access, 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.
|
||||
|For <<_offline-access, offline access>>, this is the maximum time before the corresponding offline token is revoked. This option controls the maximum time the offline token can remain active, regardless of user activity.
|
||||
|
||||
|Access Token Lifespan
|
||||
|When an OIDC access token is created, this value affects the expiration.
|
||||
|
|
@ -68,7 +68,7 @@ There is a small window of time that is always added to the idle timeout before
|
|||
|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_.
|
||||
|Permits the possibility of having independent timeouts per operation (for example, e-mail verification, forgot password, user actions and Identity Provider E-mail Verification). This field is optional. If nothing is specified, it defaults to the value configured at _User-Initiated Action Lifespan_.
|
||||
|===
|
||||
|
||||
NOTE: For idle timeouts, there is a small window of time (2 minutes) during which the session is kept unexpired. For example, when you have
|
||||
|
|
|
|||
Loading…
Reference in a new issue