[keycloak-user] Multitenancy for WAR
Travis De Silva
traviskds at gmail.com
Fri Sep 5 18:24:04 EDT 2014
sounds good. let me know once its done.
On Sat, Sep 6, 2014 at 12:14 AM, Bill Burke <bburke at redhat.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140906/7c787d0d/attachment-0001.html
More information about the keycloak-user
mailing list