<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 August 2016 at 16:54, Jared Blashka <span dir="ltr"><<a href="mailto:jblashka@redhat.com" target="_blank">jblashka@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">Thanks for the link to that JIRA. I had seen it before and wanted to find it again before emailing the list but couldn't find it.<div><br></div><div>I had some questions about the proposed solution.</div></div></blockquote><div><br></div><div>What's described in the issue is just an initial brain dump and we haven't looked into it in much detail yet. Feedback and suggestions are most welcome :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>In the propsed solution, Keycloak creates a session cookie first visit the page and updated when the user first authenticates. How does the load balancer sitting in front of Keycloak understand which Keycloak host corresponds with a given session cookie? Our current load balancers set a sticky session cookie with a node name as the cookie value.</div></div></blockquote><div><br></div><div>Not sure - If Keycloak creates the cookie the name should most likely be configurable (maybe even the value?!). If the LB creates the cookie we'd need an option to make Keycloak pick that up instead of creating its own.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Following up from that question, how would this solution work with multiple load balancer layers? We have a global load balancer that distributes traffic at a per data center level and then load balancers within each data center.</div></div></blockquote><div><br></div><div>Not sure - would that normally have two separate cookies?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Finally, it sounds like this solution would only work for clients that use the keycloak adapters? We're going to have to integrate with third-party vendors in the future and can't dictate how they write their applications. Even outside of that, we also have internal customers that own python/perl/rails applications and couldn't use a Keycloak adapter even if they wanted to because there aren't adapters available for those platforms yet.</div></div></blockquote><div><br></div><div>Pretty sure there's no standard way of doing this as there's nothing in the code-token or refresh-token requests that can be used.</div><div><br></div><div>An alternative mechanism I had in mind was that we'd allow Keycloak servers to talk to each-other to delegate requests to another node. Would that work?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div><br></div><div>Jared</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 29, 2016 at 10:08 AM, 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">We had a JPA user session provider at some point, but dropped it mainly for performance reasons and the fact it was not very well implemented. Having to write to the database for every request (including token refresh) would not be very good for performance, especially not with db replication enabled. There might be the possibility of creating a hybrid or to reduce the amount of writes to the session, but that would probably be quite a bit of work to do.<div><br></div><div>For authorization code flow we do have plans to figure out sticky sessions for that where both the requests from the browser and server-side applications ends up going to the same node. See <a href="https://issues.jboss.org/browse/KEYCLOAK-2352" target="_blank">https://issues.jboss.org/b<wbr>rowse/KEYCLOAK-2352</a>.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 24 August 2016 at 23:16, Jared Blashka <span dir="ltr"><<a href="mailto:jblashka@redhat.com" target="_blank">jblashka@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">I'm not sure why I never noticed this before, but I was doing some investigation today and couldn't find any session information actually populated in the DB tables. Both USER_SESSION and CLIENT_SESSION were empty. <div><br></div><div>After some digging in the code I saw that the only UserSesssionProvider implementation is the Infinispan-based one and it looks like the only type of user sessions that get persisted in the DB are offline sessions (via the JpaUserSessionPersisterProvide<wbr>r). </div><div><br></div><div>Was there a particular reason a JpaUserSessionProvider doesn't exist?</div><div><br></div><div>Background: We're aiming to have a highly available+resilient active-active multi-data center deployment of Keycloak. Ultimately, there should be no customer impact if a particular data center fails; there should be no IDP outage and they shouldn't have to log in again. We ran into issues with asynchronous user data replication earlier, which is why we're currently working on migrating our existing MariaDB cluster to use Galera (which has been looking pretty good so far) but it looks like we mistakenly assumed that this synchronous replication would also handle user session data.</div><div><br></div><div>Not replicating user session data across data centers is also going to cause us problems (its already caused us problems actually) when it comes to the OAuth authorization code flow as well. Since that flow involves back-channel server communication we can't guarantee that the client server will communicate with the same data center the client authenticated at. If a client calls out to the "wrong" data center, the flow will fail.</div><div><br></div><div>I can spend some time tomorrow investigating the performance when clustering infinispan across data centers, but I'm not particularly optimistic about the results.</div><div><br></div><div>Any thoughts/comments on our problem?</div><span><font color="#888888"><div><br></div><div><br></div><div>Jared</div></font></span></div>
<br></div></div>______________________________<wbr>_________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/keycloak-user</a><br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>