Keycloak Federated Identity Provider - User with multiple IdPs of the same type

[Mario Sarcher]

Hello everyone, 

there is a important feature that we would like to contribute to Keycloak in regards of the federated identity provider implementation:

https://issues.redhat.com/browse/KEYCLOAK-17028

https://keycloak.discourse.group/t/user-with-multiple-idps-of-the-same-type/7097

It would be great to get an indication from the keycloak maintainer team wether they'd consider to accept a PR from us to implement this or not?

Thanks in advance!

[Stian Thorgersen]

It's the social providers that have a limitation today that you can only have a single instance of these. Thinking about this I think it may make sense for some providers like Google to allow multiple alternatives, but then the question is how does that look like to the admin as well as the user?

Say Google for instance - sure you can configure two Google instances with different hosted domains, then you'd have a "Google 1" and a "Google 2" button on the login page. That makes little sense to me.

--
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/2323c9d1-ff31-432c-bb68-67e4ad75c18an%40googlegroups.com.

[Thomas Darimont]

Hello,

there is another issue that asks for support of multiple instances of the same IdP type: https://issues.redhat.com/browse/KEYCLOAK-9404

My take on this was the following PR where I show the underlying provider type next to the IdP alias in the list of IdPs: https://github.com/keycloak/keycloak/pull/7102

Cheers,

Thomas

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAdnTk%2B_FbCV12nQeif56MdWVOZ3O1vXHDdBRkkkhTH4mw%40mail.gmail.com.

[Stian Thorgersen]

As a general thing like that it just doesn't make all that much sense to me.

What are the use-cases when you want to be able to configure more than one instance of a given "social provider"? I think having the actual use-cases we can perhaps come up with something better than add multiple instances like this.

[Thomas Darimont]

Hello Stian,

An everyday use case for multiple IdP definitions of the same type allows logins from multiple different google apps for business domains/GitHub enterprise or GitLab domains in the same realm.
I agree that this might only apply to some IdPs, for example, Google, GitHub, GitLab, etc., but not to others, like Facebook, Instagram, Twitter, etc.

Perhaps the IdentityProvider SPI needs to be extended with an attribute that tells whether the IdP type supports multiple instances or just one.
Another option could be to specify a list of IdP identifiers that support multiple definitions.

Cheers,
Thomas

[Stian Thorgersen]

For GitHub enterprise and GitLab it makes sense, since in those cases there are multiple separate installs. 

I'd like to get more info about the Google use-case though. It doesn't make all that much sense to me to have different instances for different hosted domains, but rather to be able to perhaps support multiple different hosted domains.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAK-7U1jc075r6OVvP5Mn-1UAmQ%3Dy7r2MEWNUPZhG3syW7UPJqw%40mail.gmail.com.

[Václav Muzikář]

IMHO there's no harm in supporting multiple social providers of the same type. Not doing so seems a bit like an artificial limitation to me. Realm admin should know best whether it makes sense in their setup. It also of course depends on the given provider (private instances etc.) which changes over time. Not sure if we want to closely monitor this and selectively enable/disable multi-IdPs support for each of them as time goes.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CAJgngAczY01fMAmd0PKjBShxPLtTQ2fr1iJkT_JvSt0S8Sg-Ag%40mail.gmail.com.

--

Václav Muzikář
Senior Software Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

[Thomas Darimont]

Reposting the message from Mario Sarcher as Google Groups seems to erroneously treats his message as spam.

```

Seems that the keycloak-dev mailing group is considering my message as spam and deletes it immediately...

Posting my response to your question on use cases here Stian Thorgersen

For example with Google as an IdP where Users might have multiple accounts (work / private) it could make sense to link multiple external accounts to one Keycloak account. This increases the user experience and convenience as it would allow Users to login with all of their google accounts without switching between them.
 
Just as a side note: We have been able to successfully test it by adding multiple IdPs of the same type using the OpenID provider. Even if it's still not really a clean solution this PR would already bring an advantage:
https://github.com/keycloak/keycloak/pull/7102

```

Regarding the google apps use-case:

You might need dedicated IdP configurations (URIs, Mappers) for multiple Google Apps for business domains.

This would be very easy to do if we would support multiple Google IdP instances.

Cheers,

Thomas

[Mario Sarcher]

As stated in my initial post I don't think that its necessary to enforce multiple instances of an IdP to fulfil the described scenario.It is actually an option but a clean way from my point of view would be allowing multiple references of the same IdP type (e.g. google) at one user. 

As for example described here:

https://lists.jboss.org/pipermail/keycloak-user/2019-February/017257.html

(Nevertheless multiple instance of an IdP could make sense as well)

[Stian Thorgersen]

Probably no harm, but then again does it actually help usability? Also, what happens if you do configure multiple IdPs for things like for example Facebook? That makes no sense and might break stuff, so why should we allow it?

I'm just trying to understand the reasons for this, so we can think about perhaps a better way.

On Tue, 9 Feb 2021 at 08:54, Václav Muzikář <vmuz...@redhat.com> wrote:

[Stian Thorgersen]

That use-case makes a lot of sense, but doing it through multiple instances doesn't really. So you'd have a "Google @ Home" and "Google @ Work" button?

Wonder also if this does actually make sense? I can't see at least personally that I'd like to be able to login to the same Keycloak account both with my work and my home Google accounts, I'd probably rather have two separate accounts in Keycloak as well?

If it makes sense then I think Mario's idea of allowing linking a user to multiple accounts from the same IdP makes more sense. Not sure if it's that simple though, thinking at least about hosted domains on Google.

[Václav Muzikář]

I don't think it'd break stuff. How could it?

I can see one somewhat possible use case for Facebook. You could use different Facebook apps/clients for logging in. Those apps could be sandboxed while developing (only selected FB users are able to use it), so one FB IdP could be used for testing the app in development, the other for the rest of the cases.

[Mario Sarcher]

Yes, this is why I am suggesting to add support for multiple references of the same IdP type (e.g. google) at one user (federated-identity)!

Talking about this endpoint: 

https://www.keycloak.org/docs-api/5.0/rest-api/index.html#_addfederatedidentity

—> Currently only one entry per provider is supported per user. When doing a POST with the same provider the resulting error message is: "{"errorMessage":"User is already linked with provider"}

—> Changing the 1:1 to a 1:n relation would allow the described scenarios without having multiple idps of the same type.  

"Currently this isn't supported in Keycloak because of the foreign key constraint on federated_identity table (identity_provider, user_id).  If this constraint is changed to (identity_provider, federated_user_id, user_id) and the FederatedIdentityEntity.java class is changed to represent the new constraint then voila I can support multiple IDP's of the same type per user."

—

Mario Sarcher

Sr. Consultant, EMEA Professional Services

+49 1637199188

[Stian Thorgersen]

Trying to summarize what we've discussed so far:

1. GitLab and GitHub

----------------------------

For these it is possible to configure the URL to point to local installations. In this case we are actually talking about different IdPs, so it would make sense to allow adding multiple instances of these providers. One question here though should there be GitLab and GitHub providers that can only be used once, that point to the "public" services, then some separate providers that can be configured. That may be slightly better usability than what we have now.

2. Linking multiple accounts in one provider to the same KC account

-------------------------------------------------------------------------------------------

This mostly boils down to the foreign key constraint (at least in the simpler use-cases). This is hopefully as simple as making sure we don't have a constraint that blocks this at the DB level.

3. More advanced use-cases of 2

--------------------------------------------

This extends on 2, but would require 2 to be done first. For example for the Google provider there's an option to set the hosted domain, which blocks people with different domains. Is this as simple as allowing a list of hosted domains rather than a single domain? Are there other use-cases here?

[Thomas Darimont]

Thanks for the summary.

I think point 3. does not cover the case when you have multiple customers (customer1,customer2,...,customerN) with different 

Google Workspace (Apps for Business) domains and site configurations that should be able to use a common realm.

A customer might also have Google Workspace configured to use another third-party auth provider that they don't want to use with the Keycloak.

See "Set up single sign-on for managed Google Accounts using third-party Identity providers": https://support.google.com/a/answer/60224?hl=en 

The google IdPs for these customers are configured differently, e.g. with different IdP mappers and are hidden by default on the login page.

To send the customers to their corresponding google apps login, you can now generate a corresponding login URL which uses the kc_idp_hint parameter.
Another possibility is to create a custom domain like customer1.login.mysaas.com which will be evaluated by a special authenticator and send the login to the appropriate IdP instance.

I have found this use-case very often with customers.

Also with the other social IdPs (Facebook, etc.) it could be that you want to use different social client configurations.

[Stian Thorgersen]

On Tue, 9 Feb 2021 at 13:09, Thomas Darimont <thomas....@googlemail.com> wrote:

Thanks for the summary.

I think point 3. does not cover the case when you have multiple customers (customer1,customer2,...,customerN) with different 

Google Workspace (Apps for Business) domains and site configurations that should be able to use a common realm.

A customer might also have Google Workspace configured to use another third-party auth provider that they don't want to use with the Keycloak.

See "Set up single sign-on for managed Google Accounts using third-party Identity providers": https://support.google.com/a/answer/60224?hl=en 

The google IdPs for these customers are configured differently, e.g. with different IdP mappers and are hidden by default on the login page.

To send the customers to their corresponding google apps login, you can now generate a corresponding login URL which uses the kc_idp_hint parameter.
Another possibility is to create a custom domain like customer1.login.mysaas.com which will be evaluated by a special authenticator and send the login to the appropriate IdP instance.

I have found this use-case very often with customers.

Very often? This really sounds more like special cases to me. We're talking about a b2b type company here right? Where the customer is using Google as their IdP? Is that really that frequent setup?

The approach doesn't sound all that elegant to me either, especially the part around kc_idp_hint. How does the app decide what kc_ipd_hint to send? I imagine that the app supports multi-tenancy and has individual URLs per customer?

 

Also with the other social IdPs (Facebook, etc.) it could be that you want to use different social client configurations.

Not sure I see that use-case. To be honest I see Google as more of a special case as it really is the only one that can be used as a "proper IdP". 

[Thomas Darimont]

I'd say I see this in round about 1of 20 customers.

Having multiple different google workspace integrations is quite common, if you work with companies who are split into different sub companies that don't share a single user directory.

Most of the time, the IdP buttons are visible on the login site and the user need to choose their IdP by clicking on the proper button. In some scenarios this process is streamlined a bit by exposing the keycloak server under multiple domains, where the proper IDP to redirect to is selected based in the (forwarded) hostname in the request as you described. A different approach is to use an Identity first login flow, and redirect to the proper IDP based on user information like email domain, attribute or username format.

I have seen these approaches in combination with google, gitlab (enterprise) and github (enterprise) so far.

I have not seen multiple instances of other social login providers like facebook, twitter or instagram though.

Cheers,

Thomas

[Stian Thorgersen]

On Fri, 12 Feb 2021 at 01:00, Thomas Darimont <thomas....@googlemail.com> wrote:

I'd say I see this in round about 1of 20 customers.

Having multiple different google workspace integrations is quite common, if you work with companies who are split into different sub companies that don't share a single user directory.

Most of the time, the IdP buttons are visible on the login site and the user need to choose their IdP by clicking on the proper button. In some scenarios this process is streamlined a bit by exposing the keycloak server under multiple domains, where the proper IDP to redirect to is selected based in the (forwarded) hostname in the request as you described. A different approach is to use an Identity first login flow, and redirect to the proper IDP based on user information like email domain, attribute or username format.

I have seen these approaches in combination with google, gitlab (enterprise) and github (enterprise) so far.

Wondering then how we can provide a slightly better built-in experience around these use-cases. In general the IdP selection with displaying a long list of providers on the login page is a bit naive and only works with a handful of providers, and certainly makes it harder for folks when there are different options of "the same provider" like in this situation.

Some ideas (mainly as a discussion starter as these are all that thought through):

* Have a display condition on an IdP that allows hiding/displaying dynamically, with some built-in options

* Ask user for username first, then we can display the list of already used IdPs. This could also maybe be combined with something that controls what users can use what providers