[keycloak-dev] Session SPI for adapters

[Stian Thorgersen]

----- 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.

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