<div dir="ltr"><br><div class="gmail_extra">As per your future plans, if we can get a stateless keycloak co-location option and also enable external config in a DB when you refactor the adapter code, that should cover the needs of most developers who want to go beyond the out of the box solutions.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">BTW, I hope with the above changes it would be possible to associate one war with multiple realms and this is not a core keycloak structure design issue.</div><div class="gmail_extra">
<br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 27, 2014 at 12:47 AM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
<br>
On 2/26/2014 1:56 AM, Travis De Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
This is a good idea. I assume that we can co locate the keycloak server<br>
in a cluster environment as well right since keycloak itself does not<br>
keep any state?<br>
<br>
</blockquote>
<br></div>
We keep access code and related metadata in memory between requests at the moment :( We're planning on stuffing all information needed within the access code so the token service can be completely stateless and clusterable. We're probably a month+ away from doing that work though.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Another idea that I was thinking is can't we have a adapter that gets<br>
the realm info from a persistent store like a DB. So if we are using a<br>
database, in the adapter we can configure the database connection<br>
settings so it will pull the realm info from the DB based on the url.<br>
Note that the DB is not within keycloak but in the application side. I<br>
am thinking on the lines of how<br>
the org.jboss.security.auth.spi.<u></u>databaseserverloginmodule works. Based<br>
on a user input for the login credentials, it will get the info from the<br>
db and authenticate. In our case, there is no user input but we<br>
associate the url as the input. Putting the realm info to a db will<br>
enable us to handle larger number of realms and we can do this<br>
dynamically as well without having to add it to the standalone.xml config.<br>
<br>
But you will need to make the change to bind one war to multiple realms.<br>
As you indicated earlier, currently its one war one realm. Not sure if<br>
this is just a adapter association or goes deeper into Keycloak.<br>
<br>
</blockquote>
<br></div>
It would require a bunch of refactoring. The code is ugly. Honestly, I want to refactor this code anyways as there's not much shared code between AS7 and wildfly adapters.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Is this crazy idea? If so, then maybe the colocation option is more<br>
elegant than the url patterns.<br>
<br>
</blockquote>
<br></div>
Really depends on how you want to deploy keycloak.<div class=""><div class="h5"><span style="color:rgb(34,34,34)"> </span><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br></div></div>