[keycloak-dev] Stateless session management pushed

Fri Oct 10 07:13:27 EDT 2014

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 October, 2014 1:07:49 PM
> Subject: Re: [keycloak-dev] Stateless session management pushed
> 
> On 10.10.2014 11:03, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 9 October, 2014 12:02:07 AM
> >> Subject: [keycloak-dev] Stateless session management pushed
> >>
> >> Some summary of my changes:
> >>
> >> - Added new parameter "http_session_id" to code-to-token request. It's
> >> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
> >> saved as note in ClientSessionModel.
> >>
> >> - ResourceAdminManager refactored to use the IDs of httpSession, which
> >> are retrieved from ClientSessions. Removed username and
> >> keycloakSessionId from LogoutAction
> >>
> >> - Adapter statistics removed and everything related to them.
> >>
> >> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
> >> stateless.
> >>
> >> - Added new config option to adapters 'always-refresh-token' as we
> >> discussed. If it's true, then adapter will always send request to
> >> refresh accessToken during authentication (doesn't apply for bearer
> >> authentication, just for cookie). In the end I've used this approach
> >> instead of validating accessToken . It seems to be safer (no window) and
> >> you are always fine with 1 additional request. This option is useful in
> >> cluster in case that you have non-distributable sessions. With
> >> non-distributable it could happen that your user logged on node1, but
> >> logout request from KC is handled on node2 where httpSession doesn't
> >> exist. This is no issue with "distributable" sessions as those are
> >> replicated and hence logout can happen on any node.
> >>
> >> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
> >> fails from adapters, then httpSession is invalidated immediatelly
> >>
> >> So clustering on adapters side works well now for both Wildfly & EAP 6.3
> >>
> >>
> >> Questions & remaining work:
> >>
> >> - I am not so happy with logout for apps with non-distributable HTTP
> >> sessions. It can be handled with 'always-refresh-token' but it's
> >> performance penalty to always refresh token. The alternative might be to
> >> send also hostname in code-to-token request. This would help as
> >> ResourceAdminManager will be able to detect to which node send request
> >> for invalidate http session. Does it worth adding it?
> > Can you elaborate on the 'hostname' in code-to-token requests? I don't
> > quite get what that would do.
> Hostname where application is logged and sticky session is established,
> so keycloak knows to which host to send out-of-bound logout request.
> 
> In details:
> - User logs to product-portal and session "httpSession1" is established
> on node1
> - Now he send logout request to keycloak. Keycloak will then send
> out-of-band logout request, but it can happen that this ends on node2.
> 
> Note that this is not an issue for distributable apps. Here sessions are
> replicated so session invalidation could happen on node2 and it's
> propagated to node1 too. It's just an issue for non-distributable apps
> as session with ID "httpSession1" doesn't exist on node2, so nothing
> would be invalidated and user is still logged.
> 
> With this feature, keycloak knows to which node send invalidation
> request. Without this we would need to rely either on the logout just of
> the app, which initiated logout (no single-sign-out) or rely on browser
> redirects. Is it sufficient?

Would it not be better that Keycloak talks to the load-balancer in that case, and the LB is responsible for sending the request to the correct node. KC can send a cookie with application_state_id (or a query param) so LB knows which node to send to.

> 
> Btv. I've already worked on this yesterday and pushed it to master;-)
> >
> > I think the two options we have currently is sufficient, if properly
> > document:
> >
> > a) Logout doesn't happen until access token expires (default)
> > b) Access token is always refreshed (make sure we document the potential
> > performance hit)
> >
> > As an optimization I think we should do is that we should add a cookie that
> > is invalidated when a user logs-out. The cookie would only be invalidated
> > for the application driving the logout (retrieves the 'final' logout
> > redirect) or for applications using the coming crazy logout redirect loop.
> > My reasoning is that I think a) is sufficient for single-sign out, but if
> > a user logs-out through a specific application at least that application
> > should show a logged out state straight away.
> yep, so that's https://issues.jboss.org/browse/KEYCLOAK-702 right? And
> the cookie will be used just for apps, which don't want to have
> httpSession, correct? As for other apps, there is already cookie
> JSESSIONID, so there is no need to have another cookie imo?
> >
> >> - Is it ok to have parameter like "http_session_id" or should it be
> >> instead something more generic like "adapter_session_id" ? I am not sure
> >> if 'Http Session' is not JEE specific term? I looked at OpenID connect
> >> and there is no something like this mentioned (In fact OpenID Connect
> >> doesn't handle single-sign-out)
> > I don't think there's nothing JEE specific about a http session, but it
> > leaves some confusion to which session. What about
> > 'application_session_state'?
> yup, I think it's better. Will update it.
> >
> >> - Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
> >> for storing token in cookie instead of HttpSession) or is it ok to leave
> >> it for later? Note that for logout it will require
> >> 'always-refresh-token' or "hostname" stuff I mentioned above.
> > I think we should add it now, see my comment above (only the driving app
> > has to be logged-out immediately IMO).
> >
> >> thoughts?
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 