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

----- Original Message ----- > 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. 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.