[keycloak-user] Multi Tenancy

Stian Thorgersen stian at redhat.com
Tue Feb 25 04:56:18 EST 2014


What are developers deploying to your platform? Are they deploying WARs?

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?
* 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.

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.

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


More information about the keycloak-user mailing list