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

[Marek Posolda]

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