28 lines
1.7 KiB
Text
28 lines
1.7 KiB
Text
|
|
||
|
|
= Multi Tenancy
|
||
|
|
|
||
|
|
Multi Tenancy, in our context, means that one single target application (WAR) can be secured by a single (or clustered) Keycloak server, authenticating its users against different realms.
|
||
|
|
In practice, this means that one application needs to use different `keycloak.json` files.
|
||
|
|
For this case, there are two possible solutions:
|
||
|
|
|
||
|
|
* The same WAR file deployed under two different names, each with its own Keycloak configuration (probably via the Keycloak Subsystem).
|
||
|
|
This scenario is suitable when the number of realms is known in advance or when there's a dynamic provision of application instances.
|
||
|
|
One example would be a service provider that dynamically creates servers/deployments for their clients, like a PaaS.
|
||
|
|
* client1.acme.com
|
||
|
|
+`client2.acme.com`
|
||
|
|
+`/app/client1/`
|
||
|
|
+`/app/client2/` This chapter of the reference guide focus on this second scenario.
|
||
|
|
|
||
|
|
Keycloak provides an extension point for applications that need to evaluate the realm on a request basis.
|
||
|
|
During the authentication and authorization phase of the incoming request, Keycloak queries the application via this extension point and expects the application to return a complete representation of the realm.
|
||
|
|
With this, Keycloak then proceeds the authentication and authorization process, accepting or refusing the request based on the incoming credentials and on the returned realm.
|
||
|
|
For this scenario, an application needs to:
|
||
|
|
|
||
|
|
* web.xml
|
||
|
|
+`keycloak.config.resolver`
|
||
|
|
+`org.keycloak.adapters.KeycloakConfigResolver`
|
||
|
|
* org.keycloak.adapters.KeycloakConfigResolver
|
||
|
|
+`resolve(org.keycloak.adapters.spi.HttpFacade.Request)`
|
||
|
|
+`org.keycloak.adapters.KeycloakDeployment`
|
||
|
|
|
||
|
|
An implementation of this feature can be found in the examples.
|