[keycloak-dev] clustering Re: what's next for Alpha 3?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 20 February, 2014 4:19:41 PM
> Subject: Re: [keycloak-dev] clustering Re:  what's next for Alpha 3?
> 
> 
> 
> On 2/20/2014 11:03 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 20 February, 2014 3:47:35 PM
> >> Subject: [keycloak-dev] clustering Re:  what's next for Alpha 3?
> >>
> >>
> >>
> >> On 2/20/2014 4:36 AM, Marek Posolda wrote:
> >>> Some possible features I can think of:
> >>>
> >>> -- Clustering support -- For example if I have load-balancer and two
> >>> keycloak servers "kc1" and "kc2" and client application doesn't
> >>> communicate directly with keycloak servers but it uses loadbalancer.
> >>> Then login request could be redirected by loadbalancer to "kc1" where is
> >>> created accessCode entry in TokenManager. But when client application
> >>> sends another request to load-balancer for exchanging code for
> >>> accessToken, it could be served by "kc2", which doesn't have this code
> >>> entry --> error. I did not test this scenario, but I am assuming that it
> >>> probably won't work due to this... Do we want to support this? I've also
> >>> created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be
> >>> related to this.
> >>>
> >>
> >> Clustering really f's up the oauth/openid flow.  The only thing I could
> >> think of was that the auth-code redirect URL could contain a signed URL
> >> where the client goes to turn the code into a token.  I was surprised, I
> >> couldn't find anything in the OpenID Connect spec that covered this.
> >
> > I'm not quite following, can you specify why it f's it up?
> >
> > Couldn't we encode/encrypt everything in AccessCodeEntry into the code
> > query param? That way it wouldn't matter what instance in the cluster is
> > used.
> 
> What screws it up right now, is that our implementation keeps Accesscode
> entries and all their associated information in memory.  You'd have to
> store this information in each page displayed in the authentication
> process, then send an encrypted/signed access code that also contained
> this information when you finally redirect back to the
> application/client.  Each step in the process would have to verify and
> deserialize this information.  This would slow us down on a single
> machine deployment, but would scale and make everything stateless.

We could support both approaches and make it configurable. If you have a single server (or you can use sticky sessions), then we only pass a reference as the code. If you have a cluster and can't use sticky session we send the full AccessCodeEntry as the code.

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