On 2/26/2014 1:56 AM, Travis De Silva wrote:
This is a good idea. I assume that we can co locate the keycloak
server
in a cluster environment as well right since keycloak itself does not
keep any state?
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.
Another idea that I was thinking is can't we have a adapter that
gets
the realm info from a persistent store like a DB. So if we are using a
database, in the adapter we can configure the database connection
settings so it will pull the realm info from the DB based on the url.
Note that the DB is not within keycloak but in the application side. I
am thinking on the lines of how
the org.jboss.security.auth.spi.databaseserverloginmodule works. Based
on a user input for the login credentials, it will get the info from the
db and authenticate. In our case, there is no user input but we
associate the url as the input. Putting the realm info to a db will
enable us to handle larger number of realms and we can do this
dynamically as well without having to add it to the standalone.xml config.
But you will need to make the change to bind one war to multiple realms.
As you indicated earlier, currently its one war one realm. Not sure if
this is just a adapter association or goes deeper into Keycloak.
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.
Is this crazy idea? If so, then maybe the colocation option is more
elegant than the url patterns.
Really depends on how you want to deploy keycloak.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com