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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Marek Posolda" <mposolda(a)redhat.com&gt;, keycloak-dev(a)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(a)redhat.com&gt; >> To: "Marek Posolda" <mposolda(a)redhat.com&gt;, keycloak-dev(a)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.

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