[keycloak-dev] Session SPI for adapters

[Bill Burke]

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.



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