Troubleshooting User Linking and Redirect Issues in FusionAuth Azure SAML Integration
-
We are setting up both SP-initiated and IdP-initiated login flows with Microsoft Azure SAML for the same users.
We configured two ACS URLs in Azure:
- SP-initiated: samlv2/acs
- IdP-initiated: samlv2/acs/4e98800a-7123-479f-ace7-92502a9a47dd/39ad6a2d-2559-4b14-9b3e-a611ec4da66a
This setup works but introduces two critical issues:
1. User Linking Issues Between SP-Initiated & IdP-Initiated Logins
- When a user logs in via SP-initiated login, FusionAuth successfully creates a user link.
However, when the same user attempts to log in via IdP-initiated login, the system fails with an error:
"This account is already linked to another user. Unable to complete this login request."
- The only way to resolve this is manually deleting the user link, after which the user can log in again via IdP-initiated flow.
Questions:
- Is this behavior expected? Shouldn't FusionAuth allow a user to log in using both flows without requiring link deletion?
- Why doesn't FusionAuth automatically retrieve the IdP user ID during IdP-initiated login to match the user correctly?
- Is there a configuration option to change this behavior?
2. Controlling Redirect URLs in IdP-Initiated Logins
- Our FusionAuth application has multiple OAuth redirect URLs configured.
- During IdP-initiated login, FusionAuth always selects the first redirect URL from the list, ignoring RelayState from Azure.
- We attempted to specify a RelayState parameter in the Azure configuration, but FusionAuth does not appear to recognize it.
Questions:
- How can we ensure FusionAuth uses the correct redirect URL during IdP-initiated login?
- Does RelayState work in FusionAuth for this purpose, and if so, what is the correct way to configure it?
-
1. User Linking Issues Between SP & IdP-Initiated Logins
No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.
Troubleshooting Steps:
- Are these configured as two separate Identity Providers in FusionAuth?
- If so, ensure they are both linked to the same FusionAuth user.
- If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts.
- Is Azure using the same application for both login flows?
- If different applications are used in Azure, they may be sending different user identifiers to FusionAuth.
- Enable Debug Logging in FusionAuth:
- Go to System > Event Log and enable Debug Mode in the Identity Provider settings.
- Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins.
- If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.
2. Ensuring Correct Redirect URL in IdP-Initiated Flow
Yes, RelayState works in FusionAuth, but there are specific requirements:
Check Your FusionAuth Version
- RelayState support was added in FusionAuth 1.41.0+.
- If you are on an older version, FusionAuth will default to the first redirect URL in the list.
Correct RelayState Configuration
- Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings.
- URL-encode the redirect URL before appending it to RelayState.
- Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome
- Append the encoded URL to the ACS URL in Azure.
Example ACS URL with RelayState:
https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome
- Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.
Additional References:
Summary:
- User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes.
- RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.
- Are these configured as two separate Identity Providers in FusionAuth?
-
-
M mark.robustelli moved this topic from Q&A