<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On 2 Dec 2015 17:03, "Marek Posolda" <<a href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regarding loadbalancers, I have experience just with modJK and modCluster. Both use cookie to track to which cluster node forward the request.<br>
<br>
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.<br>
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" .<br>
<br>
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: <a href="https://tomcat.apache.org/connectors-doc/reference/workers.html" rel="noreferrer" target="_blank">https://tomcat.apache.org/connectors-doc/reference/workers.html</a> .<br>
<br>
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...<br>
<br>
Marek<br>
<br>
On 02/12/15 16:39, Bill Burke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why would you need this KEYCLOAK_LB_SESSION cookie? The loadbalancer handles all that automatically.<br>
<br>
On 12/2/2015 10:31 AM, Marek Posolda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or<br>
something. It will be created during first browser HTTP request and<br>
doesn't need to have any valuable content, the only point is to use it<br>
by loadbalancer, so it can redirect to same node.<br>
<br>
Like this:<br>
- User will send request to Loadbalancer and loadbalancer forwards to<br>
Keycloak on node1<br>
- Keycloak returns HTTP Response with username+password form and<br>
KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" )<br>
- Loadbalancer attaches the ID of node to cookie. So user will receive<br>
the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1"<br>
- User confirms the form. Loadbalancer will forward to node1 because of<br>
cookie and the form is processed on node1. Similarly all other requests<br>
( OTP etc)<br>
<br>
Just a quick though, hope I am not missing something obvious :)<br>
<br>
But for code2token, we don't have good way to enforce it on "node1" as<br>
it's out-of-bound request and won't see any cookie set by browser.<br>
That's what we discussed couple of times as you mentioned.<br>
<br>
Marek<br>
<br>
On 02/12/15 16:14, Stian Thorgersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We already have KEYCLOAK_SESSION, but that's not created until the<br>
user is authenticated<br>
<br>
On 2 December 2015 at 16:05, Marek Posolda <<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a><br>
<mailto:<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>>> wrote:<br>
<br>
On 02/12/15 16:01, Stian Thorgersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 2 December 2015 at 15:58, Marek Posolda<br>
<<mailto:<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>><a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>> wrote:<br>
<br>
btv. we actually have some optimization<br>
"auth-server-url-for-backend-requests" on adapter side. This<br>
is useful if application and Keycloak are both running on<br>
same network and using same cluster nodes. In this case,<br>
application can send all backend (out-of-bound) requests like<br>
code2token, refreshToken, to Keycloak auth-server on same<br>
cluster node.<br>
<br>
For example if there is cluster with nodes "node1" and<br>
"node2" and application request is processed on "node1", it<br>
will also use "node1" to directly access Keycloak for<br>
out-of-bound requests. So as long as there is sticky session<br>
on application side, it will defacto result in sticky session<br>
for application too.<br>
<br>
Not sure if we need to optimize too much for login. Isn't<br>
refresh token used much more often than login?<br>
<br>
<br>
If login is multiple requests (username + password, then otp)<br>
then a round robin load balancer would quite likely send the<br>
rquests to different nodes.<br>
</blockquote>
AFAIK most of loadbalancers are able to understand the cookie<br>
(like JSESSIONID ). So if we add the cookie with the node, the<br>
loadbalancer will always redirect to same cluster node.<br>
<br>
Marek<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Marek<br>
<br>
<br>
<br>
On 02/12/15 15:50, Marek Posolda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not sure if callback URI will work, because application may be able to<br>
see just the loadbalancer node and underlying cluster nodes might be<br>
hidden from it.<br>
<br>
For example if you have callback URI like<br>
<a href="http://node1:8080/auth/.../token" rel="noreferrer" target="_blank">http://node1:8080/auth/.../token</a>, application may not be able to<br>
directly access host "node1" because it's hidden and application can<br>
access justhttp://loadbalancer:8080 .<br>
<br>
Marek<br>
<br>
On 02/12/15 15:34, Bill Burke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMO, we need to highlight and document that when using a load balancer<br>
in a cluster, sticky sessions should be enabled. We might even want to<br>
consider adding support for sticky sessions for the code2token flow.<br>
The obvious reason is performance. Login can span multiple HTTP<br>
requests. If you have N nodes in the cluster with no clustering you<br>
have the possibility of the same user being retrieved from the database<br>
N times. One time for each authentication request (username/password,<br>
OTP page, required actions) and finally for the code 2 token request.<br>
Until I look into fixing it the auth SPI does a few extra redirects<br>
right now too.<br>
<br>
Code 2 token could simply have a callback URI so that the code 2 token<br>
request hits the same machine the code was created on.<br>
<br>
<br>
<br>
</blockquote>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote></div>