Re: [keycloak-dev] Stateless session management pushed

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; >>> To: keycloak-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >