Redirect to IdP automatically for specific email domains

1512 views
Skip to first unread message

Marek Posolda

unread,
Jun 15, 2020, 6:57:06 AM6/15/20
to Keycloak Dev
We have a JIRA for the $subject
https://issues.redhat.com/browse/KEYCLOAK-1515 .

This is about the ability to being able to automatically redirect to the
specified identity provider for the users with the emails of specified
domain. So for example all users with the email like "@acme.org" will be
redirected to specified IDP "acme oidc", which is configured in
Keycloak. This will be used usually with the Identity-first flow - case
when UsernameOnly authenticator is used.

How to address this? My current thinking is about development of new
authenticator. The authenticator will have the configuration option,
which will allow to specify mapping between email domains and identity
providers. For example:
acme.org -> acme OIDC provider
foo.org -> Foo SAML provider

The authenticator will need to be manually added by the administrator to
the authentication flow. Usually it will be used together with
"UsernameOnlyAuthenticator" and will be added directly after it.

Another option is to use existing "Identity Provider Redirector"
authenticator. However it seems that new authenticator implementation
will be a bit cleaner option. The current "Identity Provider Redirector"
is usually used at the beginning of the authenticator flow as it doesn't
require any user input. However the new authenticator will usually
require some user input as user will need to be known.

WDYT?

Marek

Thomas Darimont

unread,
Jun 15, 2020, 7:04:17 AM6/15/20
to Marek Posolda, Keycloak Dev

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/f41acd41-359e-9eb0-8623-49ac8b70bf92%40redhat.com.

Marek Posolda

unread,
Jun 15, 2020, 7:52:08 AM6/15/20
to Thomas Darimont, Keycloak Dev
Thanks for sharing Thomas!

I've looked at your implementation and I hope we will be able to re-use most of it. So if we agree on the details and you will be able to send the PR, it will be great :-)

Few points to clarify:

- I see your authenticator still has support for "kc_idp_hint" . I think this may not be needed in the new authenticator implementation as we already have existing "Identity Provider Redirector" in Keycloak, which covers this. Duplicated functionality may be better to avoid though? Unless we want to "combine" both authenticator implementations, but I personally not keen to that option (see my first email).

- Your authenticator has config option TARGET_IDP_ATTRIBUTE, which means that if user has specified attribute "foo" with value like "facebook", then this user will be automatically redirected to the "facebook" IDP provider. This feature was not considered in the original KEYCLOAK-1515, however it looks like nice thing, which IMO will be good to address. And I assume you have some real use for it in production?

- I see that you use attribute like EMAIL_TO_IDP_MAPPING_CONFIG_PROPERTY, which allow to map email domains to the target identity providers. It looks that attribute needs to be manually configured by administrator and it needs to have format like "acme.org/acme-oidc-provider;bar.org/bar-oidc-provider" . This is not so convenient for the administrator to configure IMO. It will be nice if we can allow administrator to use nice key/value map. I can imagine something like the existing "Advanced Claim to Role" Identity broker mapper has. See the ProviderConfigProperty.MAP_TYPE and IdentityProviderMapperModel.getConfigMap for the details. This will require some additional work and likely some minor updates in the admin console. The alternative is, that someone from Keycloak team can eventually help with this if you don't have time for this?

WDYT?

Marek

Manfred Duchrow

unread,
Jun 22, 2020, 10:39:55 AM6/22/20
to Keycloak Dev
Hi Marek and Thomas

a customer of mine is asking for a very similar feature and would be happy seeing this in the next Keycloak version.
I completely agree with your suggestion to do this in a dedicated authenticator rather than mixing it with "Identity Provider Redirector".
Furthermore I also think having a nice key/value map editing capability for configuration is preferable.

However, there are 2 additional aspects worth thinking about.
My customer has a mixed user base. That is, some users are authenticating via (various) IDPs, but there are also users managed locally in Keycloak.
So Thomas' approach should be modified to not reset current login flow if no target IDP was found. It could absolutely make sense to do context.attempted() here instead
and proceed with next authenticator (e.g. PasswordForm) in the flow. Maybe this behavior should configurable.

The other topic is: after first login via IDP the user gets copied into Keycloak (at least in my customer's use cases) and from there on should be redirected automatically
to the correct IDP, even without entering anything in any Keycloak form.
Our idea was to set a kind of "Remember IDP" cookie for the IDP used for the initial login. Another authenticator (perhaps "Identity Provider Redirector") could detect this cookie and
trigger the redirect automatically.
That would prevent the user from being asked for entering the login name twice - first in Keycloak form then on other IDP's login page.

WDYT?

Manfred

Thomas Darimont

unread,
Jun 22, 2020, 12:40:57 PM6/22/20
to Manfred Duchrow, Keycloak Dev
Hi Manfred et al,

I already have a feature branch with support for key-value pair configuration in Keycloak. It took me a lot of nerves to get it to a decent state,
however I think it's still a large hack. I'll try to upload the beast in the evening...

Regarding the dynamic redirect lookup with authflow fallback:

The cookie based solution should also work - I used this approach too a few times already, to either
remember the used IdP (Rember Me for IdP selection) or to propagate the selected targetIdp & user across multiple IdP brokering hops.

Cheers,
Thomas


--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.

Manfred Duchrow

unread,
Jun 25, 2020, 12:29:22 AM6/25/20
to Keycloak Dev
Hi Thomas,

that looks very promising. Just a little improvement suggestion.
Could you change visibility of the following method to protected?

private String determineTargetIdp(UserModel user, AuthenticationFlowContext context)

That would allow subclassing with additional custom variants of getting the target IDP.

Cheers,
   Manfred
To unsubscribe from this group and stop receiving emails from it, send an email to keyclo...@googlegroups.com.
Message has been deleted

Réda Housni Alaoui

unread,
Dec 3, 2021, 6:40:18 AM12/3/21
to Keycloak Dev
Hi everyone,

I am really interested in this feature. I may create a pull request for it.

I would like to draw your attention to realm that will use this feature while also allowing user registration.
If the username field value is used to decide to redirect or not to a third party IDP, then internal users having emails controlled by the IDP would never be able to authenticate. Therefore, it would make sense to prevent a user from entering an email address managed by a third party IDP, either at registration stage or at update stage.
I didn't yet review the possibilities offered by the Authenticator abstraction but I guess it can't be used as an email validator. 

Therefore, wouldn't it make more sense to declare the IDP controlled domain(s) inside the IDP itself? This way we could add an email validator checking that the entered email domain is not under the control of any of the registered IDP. 

What do you think of that?

Cheers,
Réda

Réda Housni Alaoui

unread,
Dec 3, 2021, 8:33:33 AM12/3/21
to Keycloak Dev
If the internal user email was not validated regarding the IDP controlled domains, I guess a workaround would be to:
- forbid internal user management from the Keycloak realm using the feature
- add a "fallback" IDP targeting another Keycloak realm that would allow internal user management
- on IDP redirect, always add the login hint and make sure the other Keycloak realm automatically redirects the user to the registration page if the username is unknown

Sven-Torben Janus

unread,
Dec 11, 2021, 4:20:43 AM12/11/21
to Keycloak Dev
Hi everyone,

I have pushed my implementation of such an authenticator to Github a few weeks ago: https://github.com/sventorben/keycloak-home-idp-discovery/
Maybe it helps for inspiration.

Regards
Sven-Torben

Ben Shaver

unread,
Dec 13, 2021, 1:19:15 AM12/13/21
to Keycloak Dev
Hey,
Maybe there is an option to take it one step further and instead of using the email is should use the ip from the x-forwarded-for header.
And then mapping ip to an idp alias it actually will map between a segment to the idp alias.
For example:
idp1,172.0.0 0
idp2,192.168.0.0

I think that it differs between organisations whether the email is the attribute that should be used for the idp mapping or a something different for example the ipaddr of the end user.

ב-יום שבת, 11 בדצמבר 2021 בשעה 11:20:43 UTC+2, Sven-Torben Janus כתב/ה:

TCHOUNKEU roland

unread,
Feb 1, 2022, 8:13:49 AM2/1/22
to Keycloak Dev
Hello Torben,
Can you help me to solve this issue? 
how to add domain names to the idp for the feature to work properly? I added several identity providers, and when I add the domain name corresponding to the identity provider, the functionality does not work.

Best Regards
Roland T.

Sven-Torben Janus

unread,
Feb 1, 2022, 12:36:11 PM2/1/22
to Keycloak Dev
Hello Roland,

since my extension is not an official Keycloak extension, please file a bug report at https://github.com/sventorben/keycloak-home-idp-discovery/issues/new/choose
Please describe in detail how you set up the authenticator and how you added the email domains.

Thanks
Sven-Torben

TCHOUNKEU roland

unread,
Feb 11, 2022, 3:50:02 AM2/11/22
to Keycloak Dev
Hello Janus,
I solved  the issue, and it was misconfigured of domains name in the respectively idp. But, i tried you kcadmin command to add domains name in the windows distribution and the command doesn't going through.

Thanks for all 

TCHOUNKEU roland

unread,
Nov 2, 2022, 6:00:29 AM11/2/22
to Keycloak Dev
Hello Torben,

I have an issue with keycloak docker version 16.1.1. I installed and configured keycloak 16.1.1 docker with keycloak-home-idp-discovery.jar(v16.0.0) and when i tried the first authentication with my idp everything is working well, but the second authentication send me an error message " Invalid username or password".

image.png



Best Regards
Roland T.

To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/d9522e13-e4e7-4ec4-aa4d-de8c2f579874n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages