[keycloak-dev] session_state changed to ClientSession id?

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 9:38:15 AM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> On 20.2.2015 09:22, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 8:54:48 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >>
> >>
> >> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>> Can I change the session_state in the access token (and refresh token)
> >>>> to point to ClientSession id instead?  Right now it points to the user
> >>>> session id.
> >>> What's the benefits of doing that?
> >>>
> >>> It might have some impact on the Infinispan provider. For best
> >>> performance
> >>> user sessions should be retrieved by id, which we won't be able to do if
> >>> we don't have it.
> >>>
> >> Access and refresh tokens should be associated with a client session so
> >> that we can track back an audit.  For claim mapping, I'm also allowing
> >> admins to map client session notes into the token.  There might be
> >> temporary protocol specific information stored there.
> >>
> >> I can just add a new client_session claim if needed.
> > If everything changes to lookup by client session id it should work fine.
> > It would require a bit of tinkering though.
> It looks to me that we may need new client_session claim? For example
> KEYCLOAK_IDENTITY cookie is not associated with any Client, but it needs
> to store id of UserSessionModel to verify if user session associated
> with cookie is still valid.

True, same goes for the iframe and if we add a session status endpoint. Basically, we'll need to be able to lookup by user id, but maybe if we split into two caches we can do both and still keep good performance?

> >
> > On a related note would it make sense to create a single client session per
> > client per user session? For example as the admin console doesn't store
> > tokens (and any client using keycloak.js is the same) a new client session
> > is created if a user refreshes the page.
> +1
> 
> Marek
> 
> >
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
>