[keycloak-dev] Session SPI for adapters

[Bill Burke]

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.

Bill

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