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.
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?
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.
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.
Really depends on how you want to deploy keycloak.
Is this crazy idea? If so, then maybe the colocation option is more
elegant than the url patterns.