My comments are inline


On Tue, Feb 25, 2014 at 8:56 PM, Stian Thorgersen <stian@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@gmail.com>
> To: keycloak-user@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user