[keycloak-dev] sticky sessions

[Stian Thorgersen]

We already have KEYCLOAK_SESSION, but that's not created until the user is
authenticated

On 2 December 2015 at 16:05, Marek Posolda <mposolda at redhat.com> wrote:

> On 02/12/15 16:01, Stian Thorgersen wrote:
>
>
>
> On 2 December 2015 at 15:58, Marek Posolda <mposolda at redhat.com> wrote:
>
>> btv. we actually have some optimization
>> "auth-server-url-for-backend-requests" on adapter side. This is useful if
>> application and Keycloak are both running on same network and using same
>> cluster nodes. In this case, application can send all backend
>> (out-of-bound) requests like code2token, refreshToken, to Keycloak
>> auth-server on same cluster node.
>>
>> For example if there is cluster with nodes "node1" and "node2" and
>> application request is processed on "node1", it will also use "node1" to
>> directly access Keycloak for out-of-bound requests. So as long as there is
>> sticky session on application side, it will defacto result in sticky
>> session for application too.
>>
>> Not sure if we need to optimize too much for login. Isn't refresh token
>> used much more often than login?
>>
>
> If login is multiple requests (username + password, then otp) then a round
> robin load balancer would quite likely send the rquests to different nodes.
>
> AFAIK most of loadbalancers are able to understand the cookie (like
> JSESSIONID ). So if we add the cookie with the node, the loadbalancer will
> always redirect to same cluster node.
>
> Marek
>
>
>
>
>>
>>
>> Marek
>>
>>
>>
>> On 02/12/15 15:50, Marek Posolda wrote:
>>
>> Not sure if callback URI will work, because application may be able to
>> see just the loadbalancer node and underlying cluster nodes might be
>> hidden from it.
>>
>> For example if you have callback URI like http://node1:8080/auth/.../token, application may not be able to
>> directly access host "node1" because it's hidden and application can
>> access just http://loadbalancer:8080 .
>>
>> Marek
>>
>> On 02/12/15 15:34, Bill Burke wrote:
>>
>> IMO, we need to highlight and document that when using a load balancer
>> in a cluster, sticky sessions should be enabled.  We might even want to
>> consider adding support for sticky sessions for the code2token flow.
>> The obvious reason is performance.  Login can span multiple HTTP
>> requests.  If you have N nodes in the cluster with no clustering you
>> have the possibility of the same user being retrieved from the database
>> N times.  One time for each authentication request (username/password,
>> OTP page, required actions) and finally for the code 2 token request.
>> Until I look into fixing it the auth SPI does a few extra redirects
>> right now too.
>>
>> Code 2 token could simply have a callback URI so that the code 2 token
>> request hits the same machine the code was created on.
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151202/641cf985/attachment-0001.html