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

Minor changes to session mgt chapter.

Browse source
This commit is contained in:
Stan Silvert 2016-06-06 13:15:23 -04:00
parent 8aec3bf8e0
commit d1c3cea744
4 changed files with 20 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
topics/sessions.adoc
View file

@ -2,9 +2,9 @@
== User Session Management
When a user logs into a realm, {{book.project.name}} maintains a user session for them and remembers each and every client they
have visited within the session. There's a lot of administrative
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 setup all the token and session timeouts there too.
can revoke tokens and set up all the token and session timeouts there too.

4
topics/sessions/administering.adoc
View file

@ -12,7 +12,7 @@ users in the realm by clicking the `Logout all` button on the right side of this
==== Logout All Limitations
Any SSO cookies set will now be invalid and clients that request authentication in active browser sessions will now have to
relogin. Only certain clients are notified of this logout event, specifically clients that are using the {{book.projec.name}}
re-login. Only certain clients are notified of this logout event, specifically clients that are using the {{book.projec.name}}
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
@ -29,7 +29,7 @@ image:../../{{book.images}}/application-sessions.png[]
==== User Drilldown
If you go to the `Sessions` tab of an individual user, you can also view there session information.
If you go to the `Sessions` tab of an individual user, you can also view the session information.
.User Sessions
image:../../{{book.images}}/user-sessions.png[]

22
topics/sessions/offline.adoc
View file

@ -2,19 +2,19 @@
=== Offline Access
The Offline access is the feature described in http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[OpenID Connect specification] .
The idea is that during login, your client application will request Offline token instead of classic Refresh token.
Offline access is a feature described in http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess[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 if user is not online
like periodic backup of some data every night etc.
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 to persist the offline token in some storage (usually database) and then use it to manually retrieve new access token from {{book.project.name}} server.
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 {{book.project.name}} server.
The difference between classic Refresh token and Offline token is, that offline token will never expire and is not subject of `SSO Session Idle timeout` .
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 you do need to use the offline token for refresh token action at least once per each 30 days ( The value can be changed in admin console.
It is `Offline Session Idle timeout` ). Also if you enable option `Revoke refresh tokens`, then each offline token can be used just once.
So after refresh, you always need to store new offline token from refresh response into your DB instead of the previous one.
However you do need to use the offline token for a refresh token action at least once per 30 days ( This value can be changed in admin console.
It is `Offline Session Idle timeout` ). 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 <<fake/../../account.adoc#_account-service, User Account Service>>.
The admin user can revoke offline tokens for individual users in admin console in the `Consent` tab of a particular user.
@ -24,7 +24,7 @@ Offline tokens can also be revoked by setting a <<fake/../../sessions/revocation
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 offline token by adding the parameter `scope=offline_access` when sending authorization request to {{book.project.name}}.
The {{book.project.name}} OIDC client adapter automatically adds this parameter when you use it to access secured URL of your application (ie.
The client can request an offline token by adding the parameter `scope=offline_access` when sending authorization request to {{book.project.name}}.
The {{book.project.name}} 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.

10
topics/sessions/timeouts.adoc
View file

@ -14,29 +14,29 @@ Let's walk through each of the items on this page.
|Configuration|Description
|Revoke Refresh Token
|For OIDC clients that 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.
|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 long than this timeout, the user session will be invalidated. How is idle time checked?
|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. Referesh 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, irregardless of activity.
a user session can remain active, regardless of activity.
|Offline Session Idle
|For <<fake/../../sessions/offline.adoc#_offline-access, 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 effects the expiration.
|When an OIDC access token is created, this value affects the expiration.
|Client login timeout
|This is the maximum time that a client has to finish the Authentication Code Flow in OIDC.
|Login timeout
|Total time a login must take. Anything beyond this time and the user will have to start the authentication process over.
|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.