[keycloak-dev] clustering Re: what's next for Alpha 3?
stian at redhat.com
Thu Feb 20 11:23:53 EST 2014
----- 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
More information about the keycloak-dev