[keycloak-dev] sticky sessions
Marek Posolda
mposolda at redhat.com
Wed Dec 2 10:00:03 EST 2015
On 02/12/15 15:58, Marek Posolda 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.
I meant: it will defacto result in sticky session for *auth-server* too.
>
> Not sure if we need to optimize too much for login. Isn't refresh
> token used much more often than login?
>
> 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
>> https://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/5fc611d4/attachment-0001.html
More information about the keycloak-dev
mailing list