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

[Bill Burke]

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.

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