[keycloak-user] Multitenancy for WAR

[Bill Burke]

I think it would be 1 day work for me, as again, I already refactored 
the adapters to support this use case.  It would just be a matter of:

* Making AdatperDeploymentContext pluggable
* Writing an AdapterDeploymentContext which could accept a URI pattern 
to extract the name of the realm.

Once I have that in place, you guys can fork it and implement anything 
you want.  What I think I want to do, is keep this SPI private until 
users like you have testdrived it.

On 9/4/2014 7:17 PM, Travis De Silva wrote:
> Hi Bill,
>
> Sorry for missing your ping as this is something that we definitely
> need. I was going down the keycloak.js path (since we use AngularJS as
> our UI layer) but doing it on the server side is so much more elegant.
>
> Picking the realm name from the URI is the way to go. Maybe we have it
> as a query parameter rather than within the path as then it is less
> invasive for the war application.
>
> I don't understand the keycloak code base enough to comment on how we
> can deploy the new AdapterDeploymentContext but what if this feature is
> plugged into the current AdapterDeploymentContext and this is a feature
> of the core product?
>
> Also with regard to getting realm information from the server using a
> shared client secret, or public clients, another way to do this might be
> to provide an alternate way to pick the keycloak.json file by storing it
> outside the war in the file system and then based on the realm name in
> the uri, pick the corresponding keycloak.json file and run the
> KeycloakDeployment. We can name the the files as keycloak-{realmname}.json
>
> Note we can keep the current functionality where it can pick it from
> within the war but if the file is missing, currently its throwing an
> exception. Maybe before we throw the exception, we also check the file
> system as well.
>
> Then maybe we don't need to load this on request but can have a
> directory scanner and whenever a new file is added or removed, it will
> automatically pick it up. Sort of how the JBoss/Wildfly deployment
> scanner works. On each request of course it will need to pick the
> correct realm to perform the authentication.
>
> This might be more elegant but once again I don't know enough of the
> core keycloak code to comment if doing this is more complex than the
> other option.
>
> Obviously these changes will not go into 1.0 release but a subsequent
> release (hopefully the first beta release after 1.0 :)
>
> Therefore it might be good to give some thought and get this right. For
> me this and the multi-lingual are the two key items that we need to tick
> off to be able to use this in a multi tenancy environment.
>
> Keen to know your thoughts.
>
> Cheers
> Travis
>
>
>
>
> On Thu, Sep 4, 2014 at 11:15 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     Travis, I did do most of the work for this.  I think I pinged you to see
>     if you still wanted the feature, but never followed through.  I'm sorry.
>
>     All this would require a shared client secret, or public clients.  It
>     would require you to extract the realm name somehow based on the current
>     HTTP request.  Probably a URI pattern.
>
>     There is an AdapterDeploymentContext class.  This class has a method:
>
>     KeycloakDeployment resolveDeployment(HttpFacade)
>
>     This method get's called every request.  You would extend this class and
>     override resolveDeployment and create (and then cache) your
>     KeycloakDeployment based on the incoming HTTP request.
>
>     The only problem is that the current code has no way for you to plug in
>     a new implementation of the AdapterDeploymentContext.
>
>     On 9/4/2014 2:36 AM, Travis De Silva wrote:
>      > Hi Stian,
>      >
>      > You proposed solution would not cover the use case where we can
>     create
>      > tenants at runtime as the realm config in the keycloak.json would be
>      > hard coded into the war.
>      >
>      > I had discussed this identical use case a while ago on this forum and
>      > Bill was planning to refactor the adapters to support this use case.
>      > Unfortunately he got caught up in other tasks and was not able to
>      > proceed on this.
>      >
>      > The discussion thread is here
>      > http://lists.jboss.org/pipermail/keycloak-user/2014-March/000062.html
>      >
>      > Basically what I believe Bill suggested which would meet this use
>     case
>      > is to:
>      >
>      >  1. Have a shared secret between clients for all realms.
>      >  2. The adapter would just extract the realm name from the request,
>      >     invoke on the keycloak server to get the public information about
>      >     the realm (i.e. public key) and then cache the information
>     locally.
>      >
>      > The key bit here is extracting the realm name from the request
>     and then
>      > pulling the realm info from the keycloak server.
>      >
>      > I had a look at the keycloak source code and I believe the magic
>     happens
>      > in the KeycloakServletExtension class under the
>      > org.keycloak.adapters.undertow package for my use case (since I
>     deploy
>      > it on wildfly)
>      >
>      > What I have got stumped is that this class gets loaded when my war is
>      > deployed and I am wondering how I can do it per request (if the
>     info is
>      > not already cached locally)
>      >
>      > Maybe with the imminent release of 1.0 (btw congrats for the
>     great work
>      > to everyone in the team and for Bill and your leadership), maybe we
>      > should start thinking about this multi tenancy use case to be
>     included
>      > in future releases.
>      >
>      > I believe that SaaS models are going to be popular and having this
>      > feature added will make keycloak a major player in this space.
>      >
>      > Cheers
>      > Travis
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > keycloak-user mailing list
>      > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/keycloak-user
>      >
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com