Configurable Parameters to be passed along from a 3rd Party via SAML.

[jobannon]

Configurable Parameters to be passed along from a 3rd Party via SAML.

Problem

Currently, when on an external IdP, if you complete a login to FusionAuth via federation, FusionAuth will only accept a login_hint parameter or a loginId. This value should be configurable or mappable (as in the case of a reconcile).

Solution

Offer a reconcile function within FusionAuth.

In other words, when a user is on AzureAD, they might send over a username parameter to complete their login. Offer a way for FusionAuth to consume this username but translate this to a loginId or any other relevant value to the integrator.

Alternatives/workarounds

When using FusionAuth as the IdP, we can accept loginId and login_hint as parameters. Hijack these values in your integration to do the mapping per federation..

Additional context

Internal ticket number: 72925

• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oapx/a8622e66-2285-43c0-bbb9-abfcecdaed86

Doc

• [x] Update SAML v2 IdP API to document new fields.
• [x] Release notes, existing IdP config, no change. New IdP config, new default to username instead of login_hint

Community guidelines

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

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.

[robotdan]

login_hint is an OIDC standard, Microsoft is always difficult and generally refuses to follow any standard. But we could review this and see if it make sense to make this parameter configurable for integration into non-standard IdPs.

[yuriy-maftiyak-verint]

+1 This issue is affecting me as well. In my case, I configured my FusionAuth instance to be an external identity provider for my AzureAD instance using SAMLv2. Azure AD sends a SAMLv2 request to the FusionAuth SAML login endpoint with the user's login in the username POST form parameter.

[joey-enfield]

For us this is a very important issue as it has a very negative impact on our end users experience.

[robotdan]

Would it be easier to just allow one to many options and document the order of precedence, for example use login_hint if defined, else username? Or to ensure we cover all possible use cases, should we just open this up to configuration?

[joey-enfield]

My vote would be whichever is faster :)

[robotdan]

Internal

• https://github.com/FusionAuth/fusionauth-app/pull/159

[robotdan]

From what I've read, specifically for Microsoft is that newer configurations use login_hint, and older ones use username. So the new config will default to enabled with login_hint, and it can be modified to be username, or anything other name that some IdP may expect.

This will only affect HTTP bindings.