FusionAuth
Federated users in an SSO session are prompted to setup MFA on subsequent logins
Federated users in an SSO session are prompted to setup MFA on subsequent logins
Description
When a user first logs in through a federated provider, FA assumes that any MFA conditions have been met and skips the MFA setup prompt. When the user arrives at the login page again, but with an SSO session, FA doesn't know that they were initially federated and forces the user to setup MFA per the tenant or application settings.
This occurs when the tenant has a tenant.multiFactorConfiguration.loginPolicy of Required.
Expected behavior
MFA prompts should be consistent in both initial and SSO session logins.
Workarounds
- set
tenant.multiFactorConfiguration.loginPolicytoEnabled. Check for MFA in the token, have application redirect to MFA enable screen if not set - use an idp_hint whenever a user initially authenticated through SAML is sent to FusionAuth login screen to forward them directly to the idp (and thence to FusionAuth).
Related
- https://github.com/FusionAuth/fusionauth-issues/issues/2005
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
Federated users in an SSO session are prompted to setup MFA on subsequent logins
Description
When a user first logs in through a federated provider, FA assumes that any MFA conditions have been met and skips the MFA setup prompt. When the user arrives at the login page again, but with an SSO session, FA doesn't know that they were initially federated and forces the user to setup MFA per the tenant or application settings.
This occurs when the tenant has a
tenant.multiFactorConfiguration.loginPolicyofRequired.Expected behavior
MFA prompts should be consistent in both initial and SSO session logins.
Workarounds
- set
tenant.multiFactorConfiguration.loginPolicytoEnabled. Check for MFA in the token, have application redirect to MFA enable screen if not set- use an idp_hint whenever a user initially authenticated through SAML is sent to FusionAuth login screen to forward them directly to the idp (and thence to FusionAuth).
Related
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
Tried the workarounds without success. Can @mmanes provide more detailed examples on the workarounds ? Thanks
@robotdan Can you shed some lights on this? I know you implemented the support for the idp_hint for federated provider such as Windows AD FS ? Thanks
This may be something we want to revisit. However, the current behavior is intended. I can appreciate that this isn't the ideal behavior for everyone.
We don't currently have a policy to restrict SSO based upon the authentication type. This means that we have to look at the current MFA policy, regardless of how the user authenticated and enforce it.
I think the larger solution will be to enforce these types of policies based upon the history of authentication on the current SSO session.
For example, we would want to take into cosinderation:
- How the user authenticated initially.
- What application the user was authorized to initially.
- Who is responsible for MFA - IdP, or FusionAuth
- https://github.com/FusionAuth/fusionauth-issues/issues/2005
- What application is being requested now.
I think we could likely do the right thing based upon that information - but we are not currently building the policy like that.
use an idp_hint whenever a user initially authenticated through SAML is sent to FusionAuth login screen to forward them directly to the idp (and thence to FusionAuth).
In testing, this option is not valid on 1.55.1
This is causing our customers a lot of pain.
We use simple themes, so IDP hints are not an option.
No matter how much we may want a user to click the big "USE SSO" button we provide, they may go to username/password because it's there. You cannot control users, they will not follow your documentation or pleas - they do what muscle memory and accidents cause them to do.
It's currently possible for a user to get into an unpassable state - they were never required to set up MFA and now they are required to supply MFA. It's not their fault they got here, its fusionauth's fault for not handling this situation correctly.
The workaround (drop to 'enabled') is not an option for our customers, because most of them require MFA per their policies, either by virtue of federation or at username/password.
