[keycloak-dev] Multi tenancy support - a proposal to discuss
Juraci Paixão Kröhling
juraci at kroehling.de
Tue Oct 21 05:47:28 EDT 2014
-----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-----
More information about the keycloak-dev
mailing list