8:38 a.m.
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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
> >> To: "Stian Thorgersen" <stian(a)redhat.com>
> >> Cc: keycloak-dev(a)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(a)redhat.com>
> >>>> To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev