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