[keycloak-dev] Session SPI for adapters

Fri Oct 3 02:38:50 EDT 2014

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?

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