6:08 p.m.
Hi Olivier,
The situation is more or less clear. Off the top of my head, there's one caveat here.
In Keycloak, almost everything is per-realm. Login screens, authentication flows, custom
authenticators etc. - all of them are defined per realm.
So, if you decide to build email -> tenant realm translation logic into Keycloak, you
will have to bind it to some well-known realm (different from tenant realms).
Master realm seems a perfect candidate here; however, there's yet another caveat,
because there were rumors that the concept of master realm can be deprecated/removed in
the future.
This of course needs to be checked with Keycloak devs. If it's true, you can create a
dedicated dummy realm just for these purposes; but for now I think it's OK to use
master realm. I'd suggest the following:
- implement custom authenticator, named e.g. "Tenant Redirector";
- using the new Theme Resource SPI, make this authenticator inject an additional screen
into the login theme, that will be email form;
- implement tenant resolution & redirection. To improve user experience, you can
extract login from email and pass it to the target realm as a parameter, so that the user
won't need to enter login name, and will be immediately taken to the password entry.
- configure master realm to use your authenticator. However, you will have to preserve the
ability for your admins to log into master realm in a traditional way. (This won't be
relevant if non-master dummy realm is used.)
Another approach is not to use custom authenticator at all, but rather implement custom
REST resource that will serve a single page (email form) upon GET and process it upon
POST.
Benefits are that custom REST resources are automatically published in all realms, so no
matter which realm you'll use for redirection.
So do these scenarios address your problem?
Cheers,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Tue, 2018-07-24 at 18:46 +0200, Olivier Rivat wrote:
Hi,
*1) introduction*
I have a multi-tenant architecture deployed with keycloak.
At first, to investigate multi-tenant architecture, I have followed what
is available within keycloak:
documentation
* https://www.keycloak.org/docs/latest/securing_apps/index.html#_multi_tenancy
examples:
* https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant
The same application is deployed in both tenants with
> * http://localhost:8080/multitenant/tenant1 and login as
user-tenant1, password user-tenant1
> * http://localhost:8080/multitenant/tenant2 and login as user-tenant2,
password user-tenant2
> When you specify http://localhost:8080/multitenant/tenant1, you are
redirected to tenant1, and you need to authenticate.
*2) description of the problem*
The issue I am facing, is that I have a customer client application,
which can redirected to several diffrent realms.
The realm selction is based on the email address.
> * user1(a)foo.com ---> should redirect to realm foo
> * user2(a)bar.com ---> shou0dl redirect to realm bar
In fact, the email analsys shoudl redirect to the correct realm (foo or
bar , or more).
Once I have the login screen of the corresponding realm1, it is the as
in /introduction/, where user authenticates normally in his specific
tenant.
*3) Authentication workflow requirement*
In fact the authentication workflow process should be as follows:
*step1*
* General welcome panel
* the user enter his email address
* based on the analysis of his welcome address, the users is
redirected to a specific authentication realm (foo or bar or more)
*step 2*
* The user enter is login/password in realm login authentication screen
After analysis, it sounds like that the keycloak authentication process
needs to be updated/modified with
1. adding an extra additional step (which is a general form asking
for email)
2. based on teh email analysis, the corresponding tenant login
screen is presented to the tenant
3. the user authenticates to the tenant with his login/password.
*4) How to move forward*
For information, Azure and atlassian already implements such a
redirection mechanism in SAAS multi tenant architecture.
Keycloak documentation does not seem to mention about such a possibility
to tailor "out of the box" the authentication workflow to our needs.
Could the mechanism described above being achieved by customizing the
authentication workflow by developing a specific authentication SPI
plugin which could handles the both steps mentioned above ?
Does this approach sounds correct to you, or is it something to rule out ?
Or woudl you advise another approach ?
Tkx for your help.
Regards,
Olivier