[keycloak-dev] Stateless session management pushed

[Bill Burke]

On 10/10/2014 11:30 AM, Marek Posolda wrote:
> 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.
>

+1 to adding multiple admin urls.  It's trivial to add right?  Probably 
won't need more than one, but it will be good to have just in case.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com