[keycloak-user] Multi Tenancy

Travis De Silva traviskds at gmail.com
Tue Feb 25 23:47:57 EST 2014


My comments are inline


On Tue, Feb 25, 2014 at 8:56 PM, Stian Thorgersen <stian at redhat.com> wrote:

> What are developers deploying to your platform? Are they deploying WARs?
>
>
Yes its WARs. Actually it would be just one war at present that consist of
all our service layer application code. (i.e. JAX-RS, EJB3, JPA, Camel and
related component libraries)


> A couple of ideas:
>
> * You could use the admin api (or model api) to create the realms for you.
> Then you could use the management interfaces to WildFly to add the KC
> config for a WAR before deploying it. You can access the management api
> through rest, or you can also call it directly from a WAR (see
> http://management-platform.blogspot.in/2012/07/co-located-management-client-for.html).
> If developers are deploying WARs you probably want to do this any ways as
> I'd imagine you'd want more control of the deployment process than just
> dumping into standalone/deployments?
>

This is an option but not very elegant.  Ideally I would prefer to handle
this from our application side without having to interact with the
application sever config, in this case Wildfly.

* Adapters aren't that complex, so you can create your own (or fork one of
> ours) that would then let you pull config from where you'd like. For
> example instead of storing config in keycloak.json you could save this in a
> database or something.
>

I guess if there is no other way, then this maybe the way to do it. Where I
can pick the realm public keys from our application DB. But would like to
explore what Bill is suggesting a bit more. If we could use wildcard uri
mappings. Will reply to his post in more detail on my thoughts.

>
> If you describe in a bit more detail exactly what you're trying to
> achieve, and also propose ideas/changes to KC, that would be great :



> With regards to LiveOak it's going to be multi-tenant, but we have
> recently decided that the container itself won't be. A single container
> instance can contain multiple apps, but not multiple tenants. Instead we'll
> leverage OpenShift and create separate gears for each tenant. There's just
> to many issues with having multi-tenancy within a single process (shared
> cpu, security, custom code, etc, etc.) and with technologies such as Docker
> creating an container instance per-tenant is light weight.
>

Yes in your model, you are spinning up separate gears (and since OpenShift
at present uses AWS separate instances). This is one way to do multi
tenancy and yes I agree with technologies such as Docker makes it more
seamless but still this would not be the most cost effective option for our
potential clients.

With our model, its actually very simple. We have one application code
(that can run in a WildFly HA environment with Infinispan etc) , one DB
with sharding. Tenants are separated by a tenant ID in the DB. Since ours
is a application for a specific domain, we can do this. For example what
the servicenow.com guys have done for IT service desks. Not sure of their
architecture but basically all tenants get the same feature set with
customisable templates allowing tenants to pick the features and
functionality that they need.

I understand this does not make sense for a platform like LiveOak, as you
guys are creating a generic platform for developers like us to develop and
deploy diverse applications for mobile and web clients. (BTW, I am excited
about the LiveOak BaaS project as well. Have developed iOS and Android push
notifications and it was really messy, especially with iOS)

Since our application is not generic but specific to a domain and business
function, its more cost effective to manage your tenants in a single
application/db. Also if your target market segment is the small business,
and you want to keep the cost low for them to subscribe to our platform,
our model makes sense. Also with all the elasticity that you get with cloud
computing today (***cough** AWS), we can scale up and down based on usage
demand.





> Cheers,
> Stian
>
> ----- Original Message -----
> > From: "Travis De Silva" <traviskds at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Sunday, 23 February, 2014 3:46:19 AM
> > Subject: Re: [keycloak-user] Multi Tenancy
> >
> > I just read the discussions on KEYCLOAK-292 on the developer mailing
> list.
> > http://lists.jboss.org/pipermail/keycloak-dev/2014-February/001378.html
> >
> > The concept of creating an application under the keycloak-admin realm for
> > each realm created looks interesting.
> >
> > When it comes to multi tenancy, I think the issue is around the
> application
> > installation process. If there is a way where we don't have to provide
> > individual application level keycloak.json's or WildFly/JBoss subsystem
> > XML's, then we are getting closer to multi tenancy. I am thinking can
> this
> > be done at a keycloak top level or the ability to use wildcards for the
> > resource elements in the json.
> >
> > Is LiveOak a multi tenancy platform? Wondering if they would need such a
> > feature.
> >
> >
> > On Sun, Feb 23, 2014 at 2:22 PM, Travis De Silva < traviskds at gmail.com >
> > wrote:
> >
> >
> >
> > I was initially under the impression that I can configure realms as
> tenants
> > and use KeyCloak for applications that are designed for multi tenancy.
> >
> > But now I have discovered that this is not possible, at least not
> possible to
> > do it on demand. I hope I am wrong and someone can correct me.
> >
> > Basically what I was trying to do was, when someone signs up to my
> > application platform, I was going to create a realm programmatically via
> the
> > API. Hence the feature request I raised to have a realm level admin
> > https://issues.jboss.org/browse/KEYCLOAK-292
> >
> > But that means, I will then have to either configure my Wildfly
> > standalone.xml config with the new realm or add the installation json to
> my
> > war and redeploy it. This is obviously not ideal for a on demand multi
> > tenant application.
> >
> > Maybe using Roles and create unique roles per tenant which hopefully I
> can do
> > programatically via the API. I think I might be able to get something
> going
> > like this but it just feels very hacky and not elegant.
> >
> > Is there any other elegant way? Is Keycloak designed for multi tenancy
> > environments?
> >
> > Cheers
> > Travis
> >
> >
> >
> > _______________________________________________
> > 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/20140226/0c1243f2/attachment.html 


More information about the keycloak-user mailing list