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