Re: [keycloak-dev] clustering Re: what's next for Alpha 3?
On 20.2.2014 16:47, Bill Burke wrote:
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.
hmm... I wonder if KC hosts could be on "internal" hosts
and application
may not directly access them? For example, I have:
loadbalancer on: http://keycloak.public.org
KC worker1 on: http://kc1.internal.org
KC worker2 on: http://kc2.internal.org
Application is somewhere on internet and it can't communicate directly
with "kc1.internal.org" just with public loadbalancer. So it seems that
it won't be able to send exchanging request to kc1.internal.org. Or am I
just misunderstood what you mean?
Maybe it could be hacked somehow at loadbalancer level, but that would
be likely proprietary solution just for that loadbalancer. Keycloak is
stateless and doesn't have anything like sticky sessions...
I can imagine that best thing to address this by either use infinispan
or by remove map entirely from TokenManager and encode whole
AccessCodeEntry to client, like Stian suggested, so exchanging request
could be served by any keycloak worker.
Marek