[keycloak-dev] Session SPI for adapters

[Bill Burke]

On 10/5/2014 4:59 PM, Marek Posolda wrote:
> On 3.10.2014 17:17, Bill Burke wrote:
>>
>> On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
>>> Let's take a step-back here and consider the problem instead of a
>>> potential solution.
>>>
>>> Currently we require all applications to have an HTTP session to keep
>>> track of the users session as well as storing the tokens. When an
>>> application is clustered this requires replicating the HTTP session
>>> to all nodes, or using sticky load balancer sessions.
>>>
>>> I think it's quite likely that some don't want to have a HTTP session
>>> and instead store the token in a cookie to make the application fully
>>> stateless. That's simple enough to add right? And storing the token
>>> in a http-only cookie should be safe as well. However, one issue
>>> remains how do we deal with single-sign out in this case. As there's
>>> no state kept in the application a logout admin event from Keycloak
>>> isn't going to work. So would be just rely on the access token
>>> expiring in this case? Or could we add something better?
>>>
>> You don't have to change anything for bearer-only apps.  Blacklist and
>> time-based revocation policies are enough.
>>
>> For browser apps, the problem is logout.  Cookie won't work for logout.
>>    While you could logout one user via a browser redirect protocol,
>> doesn't work when an admin wants to initiate a logout to one or all
>> users from the admin console.  This is because a logout generates an
>> out-of-band request to each application.  The applications match the
>> UserSessionModel id with an HTTP Session and invalidate the session.  So
>> the adapter needs a UserSessionModel->HttpSession id map.
>>
>> Maybe the access code to token protocol could be modified to send the
>> Http session id?  This could be stored in the client session and sent
>> with the out-of-band logout request.
>>
>>
> I think that this will be good . Perhaps HttpSession ID could be stored
> on ClientSessionModel as note, so no changes on UserSession model required?
>
> Related issue is that our UserSessionManagement implementations (for
> both undertow and AS7) are stateful. Is it issue to refactor them to be
> stateless? With HttpSession passed around from KC it will be possible imo.
>
> Stateful impls have issues like:
> - State in UndertowUserSessionManagement and CatalinaUserManagement is
> stored in ConcurrentHashMaps and hence is not cluster-aware . This is
> causing issues especially with logout (for example login happens on
> node1, but admin out-of-bound request is handled on node2 -> it won't be
> able to find session in it's maps -> logout won't happen as user is
> still logged on node1)
> - Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734
>
> I experimented on Friday and did prototype of UserSessionManagement
> impls backed by infinispan (this can address both cluster and memory
> leak), but tbh I am not so happy with it. IMO stateless
> UserSessionManagement is a way to go. What I can see for particular
> UserSessionManagement operations:
> - logoutKeycloakSession will be easy to handle as long as logout req
> from KC will send HttpSessionID. So we don't need any state with mapping
> from kcSessions to HttpSessions.
> - logoutUser --- Instead of sending username, Keycloak can send list of
> all HttpSessions of user for this app. Those all will be invalidated
> - logoutAll --- Both undertow Manager and org.apache.catalina.Manager
> has possibility to list all HttpSessions and invalidate them (This will
> invalidate also anonymous HttpSessions, but is this an issue?)
>
> Other methods for UserSessionManagement are for handle statistics, but
> do we really need them? Endpoint for
> PreAuthActionsHandler.handleGetUserStats() is not called from any place
> in Keycloak admin console. KC admin console is just using UserSession
> API directly. Is it an issue to remove
> PreAuthActionsHandler.handleGetUserStats() and all related methods from
> UserSessionManagement?
>

We can probably get rid of the stats.  These stat methods all existed 
prior to ClientSessionModel.


So, piggyback the http session id on access code to token and store in 
ClientSession?  Session id hopefully is usable cross-cluster in 
replicated http sessions.


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