<div dir="ltr">I guess that would work. It does add some load to the database, since we'll have to check permissions on domain object level, but that will be necessary in some form anyway (i.e. user may modify objects of type X only if they belong to him etc.). <div>
<br></div><div>The only issue is that we might need to be able to assign different roles to the same user in different application instances. I don't really see a way to implement that with the suggested approach. However, I'm also not really sure we'll need it and we could have the customer create two users if the roles are different anyway.</div>
<div><br></div><div>Just out of curiosity and since it is briefly mentioned in the user guide, what is your understanding of multitenancy and what are the use cases you are planning to support? ("Multitenancy support. You can host and manage multiple realms for multiple organizations.")</div>
<div><br></div><div>Cheers, <br>Nils<br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 31, 2014 at 9:35 PM, 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">It just seems to me that tenant is a concept specific to your<br>
application and not the security model. Why can't a realm manage<br>
multiple instances?<br>
<div class="im HOEnZb"><br>
On 5/31/2014 2:59 PM, Nils Preusker wrote:<br>
> Hi Bill,<br>
><br>
</div><div class="im HOEnZb">> our use case is as follows: we are developing an application that is<br>
> deployed as a software as a service solution. Each customer gets their<br>
> own "application instance", but all instances are served by the same<br>
> WAR. Since some customers have several instances (i.e. for departments<br>
> or divisions), it would not be accurate to say customer = realm. So we<br>
> need another level, which is what I mean when I say tenant. The users<br>
> would then be sub-elements of the tenants. However, there is one special<br>
> scenario: some customers wish to have the same users in multiple tenants.<br>
><br>
> Finally, we want to be able to add customers and instances (or tenants)<br>
> at runtime.<br>
><br>
> Mapped to my sketch from before, customers could be represented by realm<br>
> (if there is multi-realm support), "application instances" are tenants<br>
> and users can be created both on realm and on tenant level.<br>
><br>
> What do you think?<br>
><br>
> Cheers,<br>
> Nils<br>
><br>
><br>
> On Fri, May 30, 2014 at 9:13 PM, Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
</div><div class="im HOEnZb">> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>> wrote:<br>
><br>
> Why do you need to add realms at runtime? You haven't adequately<br>
> described your use case.<br>
><br>
> On 5/30/2014 2:12 PM, Nils Preusker wrote:<br>
> > Hi Bill,<br>
> ><br>
> > I guess you are right, there isn't really a difference. It would<br>
> just be<br>
> > important to be able to add realms at runtime. Are you suggesting to<br>
> > have nested realms (just replacing tenant with realm in my previous<br>
> > example)?<br>
> ><br>
> > Does that make more sense?<br>
> > Cheers,<br>
> > Nils<br>
> ><br>
> ><br>
> > On Fri, May 30, 2014 at 6:05 PM, Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
</div><div class="HOEnZb"><div class="h5">> > <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>> wrote:<br>
> ><br>
> > I don't what the different between a tenant and a realm would<br>
> be in your<br>
> > example.<br>
> ><br>
> > On 5/30/2014 5:28 AM, Nils Preusker wrote:<br>
> > > Hi Bill,<br>
> > ><br>
> > > what I was thinking of was tenants as nested element<br>
> within a realm.<br>
> > ><br>
> > > We'd like to be able to add tenants at runtime. That's<br>
> where I see a<br>
> > > problem with multi-realm support, since realms are<br>
> "hardcoded" in the<br>
> > > keycloak.json. So if you add a realm in the admin-console,<br>
> with<br>
> > > multi-realm support you'd still have to modify the<br>
> deployed WAR by<br>
> > > adding the new realm to the keycloak.json file.<br>
> > ><br>
> > > I was thinking of a structure like this:<br>
> > ><br>
> > > |- realm<br>
> > > | |-users<br>
> > > | |-realm-level-user-1<br>
> > > | |-...<br>
> > > |-tenants<br>
> > > | |-tenant-1<br>
> > > | | |-users<br>
> > > | | | |-tenant-level-user-1<br>
> > > | | | |-...<br>
> > ><br>
> > > Let me know what you think!<br>
> > > Cheers,<br>
> > > Nils<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Thu, May 29, 2014 at 11:04 PM, Bill Burke<br>
> <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
> > <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>><br>
> > > <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>>>> wrote:<br>
> > ><br>
> > > Somebody else was asking for this feature. We may have to<br>
> > add it beta 2<br>
> > > even though I wanted to have a feature freeze.<br>
> > ><br>
> > > How did you expect it to work? One guy wanted to discover<br>
> > realm per<br>
> > > request via parsing the URL. Another guy just wanted<br>
> multi-realm<br>
> > > support for bearer-only services.<br>
> > ><br>
> > ><br>
> > > On 5/29/2014 4:54 PM, Nils Preusker wrote:<br>
> > > > Hi,<br>
> > > ><br>
> > > > first of all, congrats on the beta 1 release!<br>
> > > ><br>
> > > > Here's my question: I have a WAR with a REST API<br>
> that I'm<br>
> > > securing with<br>
> > > > Keycloak. Now I'd like to add multitenancy support.<br>
> > > ><br>
> > > > If I understand the concept in keycloak correctly,<br>
> I would<br>
> > > somehow have<br>
> > > > to have several realms in the keycloak.json and the<br>
> web.xml of<br>
> > > the war,<br>
> > > > right? However there is just one realm-name<br>
> attribute in the<br>
> > > web.xml and<br>
> > > > the structure of keycloak.json also looks like it is<br>
> > intended for one<br>
> > > > realm. Am I missing something?<br>
> > > ><br>
> > > > Cheers,<br>
> > > > Nils<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > keycloak-user mailing list<br>
> > > > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>>><br>
> > > > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/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>
> > > _______________________________________________<br>
> > > keycloak-user mailing list<br>
> > > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>>><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > keycloak-user mailing list<br>
> > > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/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>
> > _______________________________________________<br>
> > keycloak-user mailing list<br>
> > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > keycloak-user mailing list<br>
> > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/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>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/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>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>