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

[Bill Burke]

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).

AdapterDeploymentContext was written to support your multi-tenant use 
case in mind.  I had hoped it was a good enough SPI.  Get your conflicts 
cleaned up and we'll merge your PR.  Great work, thanks.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com