<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
Like this:<br>
- User will send request to Loadbalancer and loadbalancer forwards
to Keycloak on node1<br>
- Keycloak returns HTTP Response with username+password form and
KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" )<br>
- Loadbalancer attaches the ID of node to cookie. So user will
receive the response with cookie KEYCLOAK_LB_SESSION with value
"foo.node1"<br>
- 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)<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 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.<br>
<br>
Marek<br>
<br>
On 02/12/15 16:14, Stian Thorgersen wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAeR3G_xAtQiA3UBvsY6Rmx+duQFJuz-nxb8DR=mHni8KA@mail.gmail.com"
type="cite">
<div dir="ltr">We already have KEYCLOAK_SESSION, but that's not
created until the user is authenticated</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 2 December 2015 at 16:05, Marek
Posolda <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 02/12/15 16:01, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 2 December 2015 at
15:58, Marek Posolda <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mposolda@redhat.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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. <br>
<br>
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.<br>
<br>
Not sure if we need to optimize too much
for login. Isn't refresh token used much
more often than login?</div>
</div>
</blockquote>
<div><br>
</div>
<div>If login is multiple requests (username +
password, then otp) then a round robin load
balancer would quite likely send the rquests
to different nodes.</div>
</div>
</div>
</div>
</blockquote>
</span> 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.<span class="HOEnZb"><font
color="#888888"><br>
<br>
Marek</font></span>
<div>
<div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div><span><font color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><span
style="color:#008000;font-weight:bold"><br>
<br>
</span> <br>
On 02/12/15 15:50, Marek Posolda
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<pre>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
<a moz-do-not-send="true" href="http://node1:8080/auth/.../token" target="_blank">http://node1:8080/auth/.../token</a>, application may not be able to
directly access host "node1" because it's hidden and application can
access just <a moz-do-not-send="true" href="http://loadbalancer:8080" target="_blank">http://loadbalancer:8080</a> .
Marek
On 02/12/15 15:34, Bill Burke wrote:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>