<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/12/15 15:58, Marek Posolda wrote:<br>
</div>
<blockquote cite="mid:565F0716.3060505@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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>
</div>
</blockquote>
I meant: it will defacto result in sticky session for *auth-server*
too.
<blockquote cite="mid:565F0716.3060505@redhat.com" type="cite">
<div class="moz-cite-prefix"> <br>
Not sure if we need to optimize too much for login. Isn't
refresh token used much more often than login?<br>
<br>
Marek<span style="color:#008000;font-weight:bold;"><br>
<br>
</span>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<br>
On 02/12/15 15:50, Marek Posolda wrote:<br>
</div>
<blockquote cite="mid:565F052A.1020001@redhat.com" type="cite">
<pre wrap="">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" class="moz-txt-link-freetext" href="http://node1:8080/auth/.../token">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" class="moz-txt-link-freetext" href="http://loadbalancer:8080">http://loadbalancer:8080</a> .
Marek
On 02/12/15 15:34, Bill Burke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>