SAML2 login fails when IdP unique identifier differs from existing IdP Link by case only

IdP Link validation is case sensitive

Description

Since upgrading to 1.48.2 some of our SAML2 IdP users have been unable to log in and are presented with the ExistingUserAlreadyLinked error. Upon investigation, we have determined that these users have existing IdP Links where the IdP User Id value in the link differs from the unique identifier in the SAML response only by case.

As far as I'm aware this was working fine (i.e. case did not matter) up to at least 1.46.0

Affects versions

1.48.2

Steps to reproduce

Steps to reproduce the behavior:

Set up a SAML2 IdP with LinkByEmailForExistingUser and with emailAddress as the nameid format
Create a user in the IdP with an email address that is all lowercase e.g. user@example.org
Create a user and add an IdP link for the above IdP with the userId being the same as the user's email but with difference in case e.g. User@example.org
Attempt to log in via the SAML2 IdP
Error is shown.

Expected behavior

I would expect this check to be case-insensitive (or at least for this to be configurable) given it's a breaking change otherwise

Event Logs

Case differs:

12/21/2023 11:53:27 PM Z Linking strategy [LinkByEmailForExistingUser]
12/21/2023 11:53:27 PM Z Resolved email to [robert.plant@fs.myorg.com]
12/21/2023 11:53:27 PM Z Resolved username to [null]
12/21/2023 11:53:27 PM Z Resolved unique Id to [robert.plant@fs.myorg.com]
12/21/2023 11:53:27 PM Z Identity provider returned a unique Id [robert.plant@fs.myorg.com].
12/21/2023 11:53:27 PM Z A link has not yet been established for this external user.
12/21/2023 11:53:27 PM Z The user with the email address [robert.plant@fs.myorg.com] already exists.
12/21/2023 11:53:27 PM Z Invoke configured lambda with Id [0e6188ae-e43d-4acb-931c-3434fb90e994]
12/21/2023 11:53:27 PM Z An existing FusionAuth is already linked to this IdP based upon the configured linking strategy.

This is unexpected and can occur if someone is attempting an account takeover, or the IdP allows for more than one user to have the same email address with a different value for the unique Id claim. While this may or may not be malicious, the login cannot be completed. If you believe the current request is valid, you will need to unlink the referenced user from this IdP.

Identity Provider Id: 52ee8838-15c8-40f5-8acc-fe50bf4da410
Identity Provider Name: SSO End to End Test
Identity Provider Linking Strategy: LinkByEmailForExistingUser

Identity Provider User Id: robert.plant@fs.myorg.com
Identity Provider User Email: robert.plant@fs.myorg.com

Existing User Id: 291d802c-79f1-4e05-b394-042a3ec9671a
Existing User Identity Provider User Id(s): Robert.Plant@fs.myorg.com
Existing User Email: robert.plant@fs.myorg.com

Case matches:

12/21/2023 11:53:48 PM Z Linking strategy [LinkByEmailForExistingUser]
12/21/2023 11:53:48 PM Z Resolved email to [robert.plant@fs.myorg.com]
12/21/2023 11:53:48 PM Z Resolved username to [null]
12/21/2023 11:53:48 PM Z Resolved unique Id to [robert.plant@fs.myorg.com]
12/21/2023 11:53:48 PM Z Identity provider returned a unique Id [robert.plant@fs.myorg.com].
12/21/2023 11:53:48 PM Z User with Id [291d802c-79f1-4e05-b394-042a3ec9671a] is linked to this external user.
12/21/2023 11:53:48 PM Z Invoke configured lambda with Id [0e6188ae-e43d-4acb-931c-3434fb90e994]
12/21/2023 11:53:48 PM Z Updating user: 
{
<snip>
}
12/21/2023 11:53:49 PM Z User is already registered for application with Id [53770139-f524-c00a-26fe-b950fb0fe91e].
12/21/2023 11:53:49 PM Z User has successfully been reconciled and logged into FusionAuth.
12/21/2023 11:53:49 PM Z Authentication type: SAMLv2
12/21/2023 11:53:49 PM Z Authentication state: Authenticated

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

Additional context

Add any other context about the problem here.

This is working as designed. The unique IdP user Id is indeed case sensitive. This value is essentially a foreign key to the user in a 3rd party IdP. For this reason, it is not normalized as FusionAuth would not know how to normalize a 3rd party unique identifier. This value could be a string, an integer, etc. To FusionAuth this is an opaque Id.

Because you are using an email address as this unique Id - user@example.org is not the same as User@example.org. Unless you know the email address to be immutable in a 3rd party system, it would not be ideal to use an otherwise mutable value as the unique user Id for an identity provider as it can change over time.

To get into this state, you may have pre-created this link using a normalized version of the Id (in this case a lowercase version of the email address known to the 3rd party IdP), or the IdP has changed how it is returning the email address in the NameID format field when selecting the Email address as the NameID format.

This should have never worked based upon these circumstances, but it may have worked due to an assumption that was made that a 3rd party IdP would always consider email as unique.

This assumption was fixed in version 1.48.0 which protects FusionAuth from account takeover when an IdP allows for non-unique email addresses.

If at all possible you should be asking the IdP to return a unique Id for the user. This can be returned in the NameID format attribute by selecting a persistent name Id (although the IdP can choose to ignore this request, so you will need to verify what the IdP is returning). Alternatively, if you already know the attribute that contains the unique Id of the user and it is not in the NameID format field, you can select this as the unique Id claim in the SAML configuration. This way FusionAuth will consume this unique Id and use it to correlate the user in the 3rd party IdP to the FusionAuth user.

In a general sense - an email address should never be considered static or adequate to be used as a unique identifier over time - unless you do want FusionAuth to consider an email change as a new user in FusionAuth. In some older systems based upon LDAP such as Lotus Notes, a user's CN (common name, non internet email address) was sometimes considered immutable, but this is rarely the case any longer.

If you have additional questions or concerns, please contact support.

Related to:

https://github.com/FusionAuth/fusionauth-issues/issues/2512

FusionAuth / fusionauth-issues