Re: [keycloak-dev] Stateless session management pushed

On 10.10.2014 13:13, Stian Thorgersen wrote: > > ----- 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. I am not convinced that going through LB is a way to go. - You need 2 hops - from KC to loadbalancer and then LB to app. This is usually unecessary imo.