[keycloak-user] Multitenancy for WAR
Nils Preusker
n.preusker at gmail.com
Sat May 31 14:59:46 EDT 2014
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 at 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 at redhat.com
> > <mailto:bburke at 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 at redhat.com
> > <mailto:bburke at redhat.com>
> > > <mailto:bburke at redhat.com <mailto:bburke at 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 at lists.jboss.org
> > <mailto:keycloak-user at lists.jboss.org>
> > <mailto: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>
> > <mailto:keycloak-user at lists.jboss.org
> > <mailto:keycloak-user at lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > 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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140531/bba61eb5/attachment-0001.html
More information about the keycloak-user
mailing list