[keycloak-dev] Session SPI for adapters

Fri Oct 3 06:30:48 EDT 2014

On 3.10.2014 08:38, 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?
One possibility I can think about is, that adapters would have some 
option to specify if they are:
- statefull (In this case HttpSession is used as is now)
- stateless (In this case token stored in the cookie like 
KEYCLOAK_PRINCIPAL)

Now for logouts I can see 2 possible flows:
1) Single sign-out which will use browser redirection for stateless apps 
(combined with backend requests for statefull apps as is now)

Details:
The option would need to be added to ApplicationModel as well. Now when 
single-sign out happens, then ResourceAdminManager.logoutApplication 
will be able to:
* In case that application is statefull, do the same as is know (invoke 
admin endpoint with httpClient)
* In case that application is stateless, it will do browser redirection 
to the application. Applications would need to have endpoint, which will 
be able to handle this and just invalidate KEYCLOAK_PRINCIPAL cookie and 
redirect back to KC. In ResourceAdminManager.logoutApplication will need 
to remove application from UserSession before this redirection happens, 
so the app logout is not invoked more times from ResourceAdminManager.

2) Logout just for the original stateless app (So not single-sign out 
for other browser stateless apps in browser):
Details:
* User invokes endpoint like 
"http://localhost:8080/customer-portal/logoutMe"
*In case that it's "stateless" app, adapter will be able to recognize it 
and it will expire KEYCLOAK_PRINCIPAL cookie. Then it will redirect to 
logout endpoint like: 
http://host/auth/realms/demo/protocol/openid-connect/logout as is now.

Flow 2 is quite easy to add and won't require any changes in Keycloak 
server. But it will logout just original application and "stateful" apps 
in this browser. "Stateless" applications != original app won't be 
logged out.

Flow 1 is complicated and requires more changes . It addresses 
single-sign out but just when invoked by user himself from his browser.

In any of those, admin user won't be able to logout and also he won't be 
able to invoke endpoints provided in ResourceAdminManager for those apps 
(statistics etc). So for stateless apps, logout by admin will always 
need to rely on the token expiration...

IMHO at least add the stateless possibility to adapters and do the 
"easy" path (flow 2) worth an effort.

Marek
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 3 October, 2014 8:27:20 AM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 2 October, 2014 5:07:09 PM
>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>
>>>
>>>
>>> On 10/2/2014 9:43 AM, Stian Thorgersen wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 2 October, 2014 3:23:46 PM
>>>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>>>
>>>>>
>>>>>
>>>>> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, 2 October, 2014 3:01:53 PM
>>>>>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
>>>>>>>> Currently adapters use the HTTP session to manage sessions. This
>>>>>>>> works
>>>>>>>> fine
>>>>>>>> for most, but I believe there's situations when something different
>>>>>>>> is
>>>>>>>> needed. For example for stateless applications. It also doesn't work
>>>>>>>> for
>>>>>>>> bearer-only applications, or oauth clients.
>>>>>>>>
>>>>>>> What doesn't work for bearer only applications? It works fine.  Bearer
>>>>>>> is completely stateless already and doesn't rely on the HTTP Session
>>>>>>> for
>>>>>>> anything.
>>>>>> Bearer-only doesn't have any way to check if a session is still valid.
>>>>>>
>>>>> If bearer-only doesn't keep track of revocation policy events then that
>>>>> is an oversight and must be fixed.  Bearer only apps are stateless and
>>>>> don't have HTTP Sessions.  Asking them to keep track of each and every
>>>>> Keycloak user session is just not feasible.  We do have a token
>>>>> validation REST resource.  Bearer-only apps could be configured to call
>>>>> back to the auth server to validate the token.
>>>>>
>>>>>>>> I propose we add a Session SPI to adapters, which allows plugging in
>>>>>>>> a
>>>>>>>> mechanism to manage user sessions. The interface would be something
>>>>>>>> along
>>>>>>>> the lines of:
>>>>>>>>
>>>>>>>> * void addSession(String userId, String sessionId)
>>>>>>>> * boolean isSessionValid(String sessionId)
>>>>>>>> * boolean removeSession(String userId, String sessionId)
>>>>>>>>
>>>>>>> We already have something.  JBossWeb session mgmt API != Undertow
>>>>>>> session mgmt so there is already an abstraction.
>>>>>>>
>>>>>>>> We could provide a few built in providers:
>>>>>>>>
>>>>>>>> * HTTP Session - store in http session as we currently do
>>>>>>>> * Infinispan - store in an Infinispan cache
>>>>>>>> * JPA - store in a database
>>>>>>>> * Keycloak Session Endpoint - we could add a session info endpoint to
>>>>>>>> Keycloak
>>>>>>>> * None - no session management (relies on expiration of access token
>>>>>>>> to
>>>>>>>> logout users)
>>>>>>>>
>>>>>>> I'm not convinced at all we need this.  We shouldn't be reimplementing
>>>>>>> Http session replication as it was already done years and years ago...
>>>>>> The whole idea is not to require a http session for applications that
>>>>>> don't
>>>>>> want that. There was already a guy requesting this on the mailing list.
>>>>>>
>>>>> For bearer only apps, HTTP session is not used.  For browser apps,
>>>>> hitting the auth server every single request is just stupid.  So, in
>>>>> that case a JWS or JWE cookie would have to hold authentication state.
>>>>> IIRC, I used to implement it that way in either Keycloak or Resteasy's
>>>>> OAuth implementation.
>>>> Who said hitting the auth-server for every request?
>>>>
>>>> With a single Infinispan cluster or a shared db multiple apps could talk
>>>> to
>>>> that to check the session instead of having to hit KC. Also, they'd be
>>>> able to be fully stateless.
>>>>
>>> So every session create and logout you want broadcasted to every single
>>> instance of every single application?  In that case, why don't you take
>>> it further and ditch the keycloak server entirely?  Store everything in
>>> infinispan.  It would also probably be pointless to use oauth, oidc, or
>>> SAML too.  If you really think that kind of architecture will actually
>>> scale, go for it.
>> Huh?
>>
>>> Bill
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev