If you don't like how we configure multi-tenet, you can provide your own implementation of AdapterDeploymentContext.  This is used to resolve the configuration elements for the application adapter.

On 3/7/2016 7:21 AM, Michel Fleur wrote:
Hello,

We are building a system with multiple services that service a set of 
user communities. Each user belongs only to one community. Each service 
potentially services all communities. Both the set of services and set 
of communities is dynamic. Each community can configure its own 
authentication scheme and UI theme. Login names - if used by the 
authentication scheme - are not necessarily unique across communities. 
The number of communities will be in the order of thousands.

As far as I can see, separation of authentication and UI themes requires 
the mapping of communities on their own dedicated Keycloak realms. 
That's okay. Our services will know against what realm to authenticate a 
user.

Naturally, I looked into you multi-tenant example (1). It does not seem 
trivial to let a service authenticate to just any realm. It doesn't feel 
right to script-or-service a lot of JSON around for each time a service 
(instance) starts or a community gets added or removed.

Is there a way to make this more dynamic? (2)  It can very well be that 
I bluntly overlook something!

GreetZ (and thanks in advance),
Michel.


(1)
Example multi-tenant service using Keycloak: 
https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant)
In our case, tenant means community.

(2)
The best I can come up with is to have each service use the REST API to 
get the realm information before the user is actually authenticated 
against it. However, can a service that is not yet registered with a 
realm also access that realm?

_______________________________________________
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