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(a)redhat.com
<mailto:bburke@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.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com