My comments are inline.
On Wed, Feb 26, 2014 at 3:10 AM, Bill Burke <bburke at redhat.com> wrote:
>
>
> On 2/24/2014 8:57 PM, Travis De Silva wrote:
> > My comments inline.
> >
> >
> > On Tue, Feb 25, 2014 at 12:31 PM, Bill Burke <bburke at redhat.com
> > <mailto:bburke at redhat.com>> wrote:
> >
> > So you want to bind a URL to a specific adapter configuration?
> > <secured-deployment> might have a <url-pattern> and/or keycloak.json
> > might be expanded to do the same.
> >
> > url-pattern could be /foo/bar/*
> >
> > or even /foo/bar/{realm}/* and keycloak adapter would pull and match
> a
> > realm configuration based on this?
> >
> > yes something like this would do.
> >
> > More comments inline
> >
> > On 2/24/2014 2:28 PM, Travis De Silva wrote:
> > >
> > > I had a look at your thoughts on how to do this with Aerogear. If
> I
> > > understand the concept correctly, with the UPS + Keycloak in one
> > bundle
> > > option, we have to update the jboss wildfly config on the fly
> > whenever
> > > we get new tenants. I did not think of this option and not sure
> > if this
> > > could be done with wildfly without having to restart wildfly, but
> > even
> > > if that is possible, that means we are going to have a large list
> of
> > > wildfly adapter profiles and I don't think that is practical.
> > Just think
> > > even if we get 200 tenants, this is going to make it very
> > complicated.
> > > Also I think the concept is one war per realm so this might not
> > even be
> > > possible for a single application multi tenant model.
> > >
> >
> > There's just no way around a large number of adapter profiles in your
> > scenario. Each realm has its own public key in which to verify
> tokens
> > with. Each of these public keys must be known to the adapter.
> >
> >
> > What about the Per war configuration? I didn't see realm level config in
> > there? So won't that work?
> >
>
> Not sure what you mean. Right now, each war can only be bound to one
> realm. I can change the adapter so that you could map URL patterns as
> stated earlier, but the realm configuration (public key, URL) has to be
> available somewhere.
>
>
My bad. Sorry. Got confused with many applications under one realm concept.
But forgot that it is still still the same realm :(
> Maybe just providing the URL of the keycloak server could be enough for
> the adapter? It pulls the realm name from the request URI, does a REST
> request to the server to see if the realm exists and pulls down
> information about the realm, then caches this information in memory.
>
> When you create a realm and the application profile within that realm,
> you can just make sure that each of these realm/application combos has
> the same client secret. (Or we could provide an option to allow public
> non-confidential clients).
>
Another thing we could do (and what I want to do anyways) is to provide
> colocation aware adapters that can interact with the keycloak apis
> directly intra-JVM if the keycloak server is deployed on the same
> machine. This would help implement a multi-tenant adapter.
>
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?
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.
Is this crazy idea? If so, then maybe the colocation option is more
elegant than the url patterns.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140226/a658ce24/attachment-0001.html