<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 02/12/15 16:01, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAemMEbZaQsqLkdsPXsodTUNhhWX2Q1_+6yspVYiG6MyjQ@mail.gmail.com"
      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">&lt;<a moz-do-not-send="true"
                href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</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>
    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.<br>
    <br>
    Marek<br>
    <br>
    <blockquote
cite="mid:CAJgngAemMEbZaQsqLkdsPXsodTUNhhWX2Q1_+6yspVYiG6MyjQ@mail.gmail.com"
      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 class="HOEnZb"><font color="#888888"><br>
                      <br>
                      Marek</font></span>
                  <div>
                    <div class="h5"><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 class="h5">
                    <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">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>
  </body>
</html>