New IdP linking strategy - Link on Email. Only if user is associated to Identity Provider.

[jobannon]

Problem

I have a user@user.com and I want to associate them with a known identity provider, but I do not know the ID of the user in that upstream IdP (yet). We want to force a user to use a certain IdP when federating.

Solution

Make an Associate API

POST /api/identity-provider/associate
{
  "identityProviderAssociation" : {
    "identityProviderId" : "f50dbb83-4cc2-4e5e-aece-9efe068bddd9",
    "userId" : "fbf0e652-b2b5-45eb-b9c9-d4640889740b",
  }
}

This would allow a user to be associated with an identityProvider without knowing about the user's Id information in the upstream IdP.

Additional context

https://inversoft.slack.com/archives/C0429LK5A9J/p1692901048509939

Related

• Require user interaction on email based link workflows when cross device #2443
• Verify edited Email in User Self Service form #2445
• Consider making the IdP Link and Unlink webhooks transactional #1710

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[jthughey]

With our setup, we have our user pool and our Identity Providers in a single tenant.

Given the existing linking strategies (username, mail, etc.) there's no way to restrict the set of Identity Providers that a user account is allowed to link with. For us, this causes the following risk to manifest, an IdP could be hacked allowing a cross domain account takeover to occur. To mitigate this risk we'd like the ability to enforce linking restrictions. A compromised IdP that impacts the users that are linked to the Idp is bad. But a compromised IdP that impacts the entire pool of users is really really bad.

#Example
With the existing "Link On Email" linking strategy, the following situation could occur. (This scenario also exists for the "Link on Username" strategy as well.)

If I put in jon.smith@example.com as my email address to start the login process but the Example IdP returned robotdan@fusionauth.io as my email address then my Example IdP account would be linked to the user account with robotdan@fusionauth.io as the email, allowing for an account takeover of the robotdan@fusionauth.io account.

To remove this risk, we want to restrict linking by email domain (e.g., fusionauth.io) to start, but in the future want the flexibility to manage user account to IdP associations with multiple domains and IdPs via being explicitly allowed.

example:
justin@example.com -> IdP(example.com)
justin@example.com -> IdP(fusionauth.io)

#Current Options

1. Set the linking strategy to "Disabled", and then write an entirely custom login workflow where we could intercept the authentication request and then manually link the IdP request to the user account in FusionAuth based on our own pre-defined rules.

2. Use a webhook and the "user.identity-provider.link" event, but it's not transactional so we wouldn't be able to intercept the link and prevent the linking with an error response.

3. Use "Link On Email. Do not create the user if they do not exist." and let the link occur. Then check every time a user executes a login via the "user.login.success" event with a webhook that checks the the authenticating IdP against an allowed set of IdPs associated to the user account. If the user is attempting to login through an IdP that they shouldn't then we fail the login. This isn't the best solution as a link from the IdP to the user account will still occur.

We're leveraging option 3 at this time.

#Solution
The solution as documented above by @jobannon covers the process we'd like to be using, setting up a direct relationship between a user account and an IdP, without a user identifier, prior to the user authenticating into FusionAuth for the first time.