[keycloak-dev] Stateless session management pushed

Fri Oct 10 11:30:20 EDT 2014

On 10.10.2014 13:13, Stian Thorgersen wrote:
>
> ----- 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.
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.

- I am not sure there is some generic way how to pass sessionId via 
loadbalancer. For LB I know (mod_cluster, mod_jk) you can pass it via 
"jsessionid" parameter, but is this not something JEE specific? Will it 
work for other application types, like non-java apps?

- For Undertow, sessionId actually sent to Keycloak contains just ID 
(not the node identifier) - should be likely possible to solve though...

- Small disadvantage is, that cluster node with KC itself may be on 
private network with some firewall and limited access. And it may not 
itself know the host with LB. For example user is accessing KC 
loadbalancer under URL: "http://www.frontend-auth-server.com/auth" and 
this host may not be known to the cluster node itself (not sure if it's 
really an issue for real environments or not. Actually I have issues 
with this on docker setup ;-)

Marek
>
>> 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
>>>>
>>