[keycloak-dev] Session duration for clients
Stian Thorgersen
sthorger at redhat.com
Tue Nov 19 05:36:14 EST 2019
Yes, a client session can't have a longer expiration than the SSO session.
The proposed changes enable the use-case where you want users to remain
logged-in, but still have shorter sessions (and also require re-auth) for
specific clients.
On Mon, 18 Nov 2019 at 14:56, Ricardo Martin Camarero <rmartinc at redhat.com>
wrote:
> Hi,
>
> Thanks for the explanation Stian. So the client max sso and idle
> timeouts should be less or equal than the respective realm values. I had
> understood that any value could be set at client level.
>
> Regards!
>
>
> On 11/18/19 1:41 PM, Stian Thorgersen wrote:
> > Added a JIRA here
> > https://issues.jboss.org/browse/KEYCLOAK-12103 trying to capture the
> > idea in more detail.
> >
> > On Mon, 18 Nov 2019 at 13:27, Stian Thorgersen <sthorger at redhat.com
> > <mailto:sthorger at redhat.com>> wrote:
> >
> > Client session max and idle would not affect how sessions are
> > removed from memory. The session in the memory is the SSO session,
> > not the session for individual clients.
> >
> > Client session max and idle in regards to OIDC only control the
> > expiration time of the tokens. Refresh tokens and access tokens
> > are only valid up to client session idle. Further, the refresh
> > token can only be refreshed up to client session max. The latter
> > just means we'd need to add an additional claim to the refresh
> > tokens (which should be opaque to tokens anyways). Once the
> > refresh token is expired the client would have to obtain new
> > tokens, which as long as the SSO session is still valid it can do
> > without user having to enter credentials.
> >
> > For SAML there is no refresh token as such the Client Session Idle
> > would not be applicable. Instead the SAML assertion would be valid
> > for Client Session Max, and the SAML client would fetch a new
> > assertion which again it could do without user entering
> > credentials as long as the SSO session is still valid.
> >
> > On Fri, 15 Nov 2019 at 15:43, Ricardo Martin Camarero
> > <rmartinc at redhat.com <mailto:rmartinc at redhat.com>> wrote:
> >
> > Hi,
> >
> > Stian, note that changing the SSO max time and SSO idle time also
> > affects in how the sessions are removed from memory. If the
> > max and/or
> > idle is changed per client, the current removeSessions [1]
> > should be
> > modified to consider the timeouts per client (now only realm
> > is taken
> > into account). Those timeouts do not only affect token
> generation.
> >
> > Regards!
> >
> >
> > [1]
> >
> https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/InfinispanUserSessionProvider.java#L489
> >
> >
> > On 11/12/19 4:24 AM, 田畑義之 / TABATA，YOSHIYUKI wrote:
> > > Hi,
> > >
> > > I agree with this idea.
> > > This idea will achieve our use case described in the thread
> [1].
> > > Do you have any plans to implement this?
> > >
> > > [1]
> >
> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012530.html
> > >
> > > Regards,
> > > Yoshiyuki Tabata
> > > Hitachi, Ltd.
> > >
> > > -----Original Message-----
> > > From: keycloak-dev-bounces at lists.jboss.org
> > <mailto:keycloak-dev-bounces at lists.jboss.org>
> > <keycloak-dev-bounces at lists.jboss.org
> > <mailto:keycloak-dev-bounces at lists.jboss.org>> On Behalf Of
> > Stian Thorgersen
> > > Sent: Friday, November 08, 2019 6:09 PM
> > > To: keycloak-dev <keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>>
> > > Subject: [!][keycloak-dev] Session duration for clients
> > >
> > > Today we have SSO session max and idle, but there is no way
> > to control
> > > duration for individual clients.
> > >
> > > One side-effect of this is that if the SSO session max is
> > very large all
> > > refresh tokens will have a long expiration time.
> > >
> > > It is also related to max_age parameter. As tokens have a
> > long expiration
> > > the only way to control it is the client has to manually
> > check auth_time in
> > > the tokens.
> > >
> > > One idea is that we could introduce a Client Session Max and
> > Idle. The
> > > realm would allow setting a default value, but it would also
> > be possible to
> > > override on a per-client basis. If not set for realm or
> > client it would
> > > fallback to SSO Session Max/Idle
> > >
> > > For Client Session Max implementation should be pretty
> > straight forward.
> > > When issuing tokens we make sure the expiration is set
> > according to the
> > > Clients Session Max.
> > >
> > > For Client Session Idle implementation should also be pretty
> > straight
> > > forward. Tokens would only be valid if within Client Session
> > Idle. As long
> > > as clients refresh tokens they will get newly issued tokens
> > that would be
> > > within the Client Session Idle, up until they reach Client
> > Session Max when
> > > the refresh token would no longer be valid and the client
> > would need to do
> > > a new authentication request to obtain new tokens.
> > >
> > > We should also add default_max_age to clients, which would
> > make it possible
> > > to easily configure re-authentication for specific clients.
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > >
> >
> https://clicktime.symantec.com/35pw2iShL84hrZog1HQKXcD7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > <mailto:keycloak-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > --
> >
> > Ricardo Martín Camarero
> >
> > Software Engineer
> >
> > Red Hat <https://www.redhat.com>
> >
> > <https://www.redhat.com>
> >
> --
>
> Ricardo Martín Camarero
>
> Software Engineer
>
> Red Hat <https://www.redhat.com>
>
> <https://www.redhat.com>
>
>
More information about the keycloak-dev
mailing list