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

[Bill Burke]

On 2/20/2014 11:23 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at 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 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.
>
> 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.
>

We'll profile it.  It just might be that this verification/unmarshalling 
is only a small percentage of each overall request.


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