[keycloak-dev] sticky sessions

[Bill Burke]

Why would you need this KEYCLOAK_LB_SESSION cookie?  The loadbalancer 
handles all that automatically.

On 12/2/2015 10:31 AM, Marek Posolda wrote:
> Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or
> something. It will be created during first browser HTTP request and
> doesn't need to have any valuable content, the only point is to use it
> by loadbalancer, so it can redirect to same node.
>
> Like this:
> - User will send request to Loadbalancer and loadbalancer forwards to
> Keycloak on node1
> - Keycloak returns HTTP Response with username+password form and
> KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" )
> - Loadbalancer attaches the ID of node to cookie. So user will receive
> the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1"
> - User confirms the form. Loadbalancer will forward to node1 because of
> cookie and the form is processed on node1. Similarly all other requests
> ( OTP etc)
>
> Just a quick though, hope I am not missing something obvious :)
>
> But for code2token, we don't have good way to enforce it on "node1" as
> it's out-of-bound request and won't see any cookie set by browser.
> That's what we discussed couple of times as you mentioned.
>
> Marek
>
> On 02/12/15 16:14, Stian Thorgersen wrote:
>> 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
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     On 02/12/15 16:01, Stian Thorgersen wrote:
>>>
>>>
>>>     On 2 December 2015 at 15:58, Marek Posolda
>>>     <<mailto:mposolda at redhat.com>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 justhttp://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 list
>>>>         keycloak-dev at lists.jboss.org
>>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>>
>

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