Hi Bill,

our use case is as follows: we are developing an application that is deployed as a software as a service solution. Each customer gets their own "application instance", but all instances are served by the same WAR. Since some customers have several instances (i.e. for departments or divisions), it would not be accurate to say customer = realm. So we need another level, which is what I mean when I say tenant. The users would then be sub-elements of the tenants. However, there is one special scenario: some customers wish to have the same users in multiple tenants. 

Finally, we want to be able to add customers and instances (or tenants) at runtime.

Mapped to my sketch from before, customers could be represented by realm (if there is multi-realm support), "application instances" are tenants and users can be created both on realm and on tenant level.

What do you think?

Cheers,
Nils


On Fri, May 30, 2014 at 9:13 PM, Bill Burke <bburke@redhat.com> wrote:
Why do you need to add realms at runtime?  You haven't adequately
described your use case.

On 5/30/2014 2:12 PM, Nils Preusker wrote:
> Hi Bill,
>
> I guess you are right, there isn't really a difference. It would just be
> important to be able to add realms at runtime. Are you suggesting to
> have nested realms (just replacing tenant with realm in my previous
> example)?
>
> Does that make more sense?
> Cheers,
> Nils
>
>
> On Fri, May 30, 2014 at 6:05 PM, Bill Burke <bburke@redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
>     I don't what the different between a tenant and a realm would be in your
>     example.
>
>     On 5/30/2014 5:28 AM, Nils Preusker wrote:
>      > Hi Bill,
>      >
>      > what I was thinking of was tenants as nested element within a realm.
>      >
>      > We'd like to be able to add tenants at runtime. That's where I see a
>      > problem with multi-realm support, since realms are "hardcoded" in the
>      > keycloak.json. So if you add a realm in the admin-console, with
>      > multi-realm support you'd still have to modify the deployed WAR by
>      > adding the new realm to the keycloak.json file.
>      >
>      > I was thinking of a structure like this:
>      >
>      > |- realm
>      > |  |-users
>      > |     |-realm-level-user-1
>      > |     |-...
>      > |-tenants
>      > |  |-tenant-1
>      > |  |  |-users
>      > |  |  |  |-tenant-level-user-1
>      > |  |  |  |-...
>      >
>      > Let me know what you think!
>      > Cheers,
>      > Nils
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      > On Thu, May 29, 2014 at 11:04 PM, Bill Burke <bburke@redhat.com
>     <mailto:bburke@redhat.com>
>      > <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
>      >
>      >     Somebody else was asking for this feature.  We may have to
>     add it beta 2
>      >     even though I wanted to have a feature freeze.
>      >
>      >     How did you expect it to work?  One guy wanted to discover
>     realm per
>      >     request via parsing the URL.  Another guy just wanted multi-realm
>      >     support for bearer-only services.
>      >
>      >
>      >     On 5/29/2014 4:54 PM, Nils Preusker wrote:
>      >      > Hi,
>      >      >
>      >      > first of all, congrats on the beta 1 release!
>      >      >
>      >      > Here's my question: I have a WAR with a REST API that I'm
>      >     securing with
>      >      > Keycloak. Now I'd like to add multitenancy support.
>      >      >
>      >      > If I understand the concept in keycloak correctly, I would
>      >     somehow have
>      >      > to have several realms in the keycloak.json and the web.xml of
>      >     the war,
>      >      > right? However there is just one realm-name attribute in the
>      >     web.xml and
>      >      > the structure of keycloak.json also looks like it is
>     intended for one
>      >      > realm. Am I missing something?
>      >      >
>      >      > Cheers,
>      >      > Nils
>      >      >
>      >      >
>      >      >
>      >      >
>      >      > _______________________________________________
>      >      > keycloak-user mailing list
>      >      > keycloak-user@lists.jboss.org
>     <mailto:keycloak-user@lists.jboss.org>
>     <mailto:keycloak-user@lists.jboss.org
>     <mailto:keycloak-user@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@lists.jboss.org
>     <mailto:keycloak-user@lists.jboss.org>
>     <mailto:keycloak-user@lists.jboss.org
>     <mailto:keycloak-user@lists.jboss.org>>
>      > https://lists.jboss.org/mailman/listinfo/keycloak-user
>      >
>      >
>      >
>      >
>      > _______________________________________________
>      > keycloak-user mailing list
>      > keycloak-user@lists.jboss.org <mailto:keycloak-user@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@lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user