<div dir="ltr">We did discuss this quite a lot when we did clustering initially, and we never found an elegant solution to doing sticky sessions.</div><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2015 at 15:55, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@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 dir="ltr">Adding callback URI to the token would also make it very Keycloak specific. So it would only work for Keycloak adapters.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2015 at 15:50, Marek Posolda <span dir="ltr"><<a 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">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 just <a href="http://loadbalancer:8080" rel="noreferrer" target="_blank">http://loadbalancer:8080</a> .<br>
<span><font color="#888888"><br>
Marek<br>
</font></span><span><br>
On 02/12/15 15:34, Bill Burke wrote:<br>
> 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>
<br>
</span><div><div>_______________________________________________<br>
keycloak-dev mailing list<br>
<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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>