[keycloak-dev] clustering Re: what's next for Alpha 3?
bburke at redhat.com
Thu Feb 20 11:19:41 EST 2014
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.
JBoss, a division of Red Hat
More information about the keycloak-dev