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(a)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(a)redhat.com
> <mailto:sthorger@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(a)redhat.com <mailto:rmartinc@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/mai...
>
>
> 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(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>
> <keycloak-dev-bounces(a)lists.jboss.org
> <mailto:keycloak-dev-bounces@lists.jboss.org>> On Behalf Of
> Stian Thorgersen
> > Sent: Friday, November 08, 2019 6:09 PM
> > To: keycloak-dev <keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >
>
https://clicktime.symantec.com/35pw2iShL84hrZog1HQKXcD7Vc?u=https%3A%2F%2...
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@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>