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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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 list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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?

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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 02/12/15 16:01, Stian Thorgersen wrote: On 2 December 2015 at 15:58, Marek Posolda <mposolda(a)redhat.com&gt; 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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 02/12/15 16:01, Stian Thorgersen wrote: >> >> >> On 2 December 2015 at 15:58, Marek Posolda >> <<mailto:mposolda@redhat.com>mposolda@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(a)lists.jboss.org >>> <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > >

Regarding loadbalancers, I have experience just with modJK and modCluster. Both use cookie to track to which cluster node forward the request. Classic servlet applications usually use JSESSIONID cookie. So when node returns JSESSIONID with the HttpSession ID from servlet application like "1234" , the loadbalancer will attach the ID of node to it. So the user's browser will receive the JSESSIONID cookie with value "1234.node1" . Then when user sends another request to loadbalancer, loadbalancer will read the cookie and it knows that it needs to forward request to "node1" . In Keycloak, we don't have HttpSession and JSESSIONID , but we can use any other cookie ( like KEYCLOAK_LB_SESSION ). AFAIK it's configurable on loadbalancer side, what is the name of the cookie to use. For example in modjk it's the property "session_cookie" . See: https://tomcat.apache.org/connectors-doc/reference/workers.html . Or alternatively we can use the cookie name JSESSIONID to not require configuration changes on loadbalancers, just not sure if it's not too confusing as we don't have real HttpSessions... Marek On 02/12/15 16:39, Bill Burke wrote: > 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(a)redhat.com >>> <mailto:mposolda@redhat.com>> wrote: >>> >>> On 02/12/15 16:01, Stian Thorgersen wrote: >>> >>>> >>>> >>>> On 2 December 2015 at 15:58, Marek Posolda >>>> <<mailto:mposolda@redhat.com>mposolda@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(a)lists.jboss.org >>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> <mailto:keycloak-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> >> >

On 12/2/2015 12:46 PM, Stian Thorgersen wrote: > Wonder if we could do something similar with code 2 token. Could we not > set a cookie there as well? Then at most there would be two nodes for > one user. > > Alternative is to update code 2 token so it doesn't require the user > model. That would be more elegant. We could do that by making sure user > sessions are updated when required if user model changes. > You could optimistically create the token and store it within the client session. But then your overhead is in replication? Then again is replicating a few kilobytes that big of a deal?

We don't replicate the session. It's a distributed cache so it's fetched internally from the correct node. For refresh token maybe we could update the user session for a user that they need to be checked against the user changes? On 2 December 2015 at 18:58, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: On 12/2/2015 12:54 PM, Bill Burke wrote: > > > On 12/2/2015 12:46 PM, Stian Thorgersen wrote: >> Wonder if we could do something similar with code 2 token. Could we not >> set a cookie there as well? Then at most there would be two nodes for >> one user. >> >> Alternative is to update code 2 token so it doesn't require the user >> model. That would be more elegant. We could do that by making sure user >> sessions are updated when required if user model changes. >> > > You could optimistically create the token and store it within the client > session. But then your overhead is in replication? Then again is > replicating a few kilobytes that big of a deal? > Answering my own question...It probabbly isn't a big deal as you are already replicating the client session anyways. Doesn't help refresh token though. Refresh token needs to verify the user is still enabled. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev