[keycloak-dev] Multi tenancy support - a proposal to discuss

[Stan Silvert]

I don't know if this helps your use case, but you will soon be able to 
deploy more than one Keycloak Auth Server in the same WildFly instance.  
Each server will have a different web context and be completely independent.

So you would have something like:
http://localhost:8080/authserverone/admin/index.html
http://localhost:8080/authservertwo/admin/index.html

In standalone.xml, you will have:
         <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
             <auth-server name="authserverone">
                 <enabled>true</enabled>
<web-context>authserverone</web-context>
             </auth-server>
             <auth-server name="authservertwo">
                 <enabled>true</enabled>
<web-context>authservertwo</web-context>
             </auth-server>
         </subsystem>

You will also need to associate each one with a different datasource 
using keycloak-server.json.

On 10/21/2014 5:47 AM, Juraci Paixão Kröhling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> As part of a task for another project that could benefit from having
> multi tenancy support in Keycloak, I scratched a proposal for this
> feature and sent it as a PR (it's now on the 'multi-tenant-adapter'
> branch).
>
> In my view, multi tenancy is defined as "a way to determine the realm
> of an application based on the incoming request". So, a single
> application is deployed to a single application server, but the users
> could belong to different realms, depending on the hostname, or an
> HTTP header, or path, ... This is a typical SaaS scenario.
>
> There's already a good "multi tenant" support at the server level, in
> the form of a realm, so, I haven't bothered much in checking if it
> would make sense to add this kind of support on the server (ie: a
> "tenants" property in a realm).
>
> The commit [1] adds a new abstract class, KeycloakConfigResolver, that
> is meant to be extended by an application developer and builds a
> KeycloakDeployment.
>
> If an application (war) contains the context parameter
> "keycloak.config.resolver" and points to a class existing on the
> deployed WAR, it uses that on the AdapterDeploymentContext. On each
> incoming request, this resolver is used to build a KeycloakDeployment,
> used during the actual authentication/authorization, not changed by
> this commit except for adding the HttpFacade.Request in some places.
>
> When doing a rebase this morning to send the PR, I got a few conflicts
> due to the clustering support. I don't know the implications of that
> yet, as I'm not familiar with the clustering support, but I think a
> proper final solution is to split KeycloakDeployment , so that
> information about the target Keycloak server is stored in a different
> place than the realm information.
>
> I have tested this with a custom application, available at [2]. It was
> tested with a Keycloak 1.0.1.Final server and with the custom adapters
> deployed on Wildfly 8.1.0.Final and seem to work fine.
>
> What I'm particularly interested in knowing is:
>
> - - Is this the right direction to implement this feature? I have mixed
> feelings about doing this at the "AdapterDeploymentContext" level
> (mixed, but more on the positive side).
> - - Should I refactor KeycloakDeployment , to split the server from the
> realm information?
>
> 1 -
> https://github.com/keycloak/keycloak/commit/37a48d49e10798d10f4509848c04ecb257f38d0f
>
> 2 - https://github.com/jpkrohling/keycloak-tenants-poc
>
> Best,
> Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJURiuwAAoJEDnJtskdmzLMx+AH/1pMBIeB40Tq5BTj6vciXJIc
> ZJgcdgU+UXJbW0GLO4Nio6llSR4IprKfzkXUe/JRgfUdTFEeO90plWFCJ9k0YfZP
> GaldCUdNZKwqWqiw6ZcQWIRzDeyruX0nyv08XGJ44VDtUUhXdNLv3kDDCO4hHnHd
> gt5uFISj0U+JsgXR/1vXnHXzGE8hNORTe/uw+RSkjhpk6bmgbpUBSE5760RKMKNN
> IhzS1AgU/9SRUBs7yaV9w2KOs9+KUQ2aAu1ABqPt5+T2EDqWfqD+chCuM5lz91te
> GwXN/ZsRLTlSbb68EkyMOaWV5sM+FUA+RBG2EN5SPJcrjYxnqXp4I9TJdVa57t0=
> =9d5O
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev