@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

@imsurya2442

Thanks for the question.

This may be related https://github.com/FusionAuth/fusionauth-issues/issues/2019. If it is, there is a workaround listed that you could attempt.

Thanks,
Josh

@johnathon

One approach would be to append the parameter idp_hint to the login URL to redirect a user to the appropriate IdP login page. Please read the hints section in our documentation for more information.

Another way to disable the password and email login for a user would be to set their password to a random 25-character string. This would make the password essentially impossible to brute force and thus impossible for them to log in via the hosted login page.

Use the managed domains feature. From the docs:

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

Documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

@chirag have you seen these? https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

Reviewing them and mapping your use case on to them may be helpful.

Generally this is a dev time message. Although depending upon your integration, it may be possible that an end user would see that message.

You could try adding a message to your theme:

[MultiTenantSSONotSupported]=n/a

In general, any user facing message can be overridden by your theme.

You’re correct. That is not a standard redirect URL. You could easily build some glue code to to look like an OpenID Connect compliant SP and then handle the redirect yourself. I am not super familiar with some of the OpenID Connect server options, but something like Hydra may be useful here. Perhaps some others from the community here can help with off the shelf options if you don’t want to code it yourself.

But coding it yourself may be the easiest, if you coded it in Node or something like that, it would be super simple, you’d have FusionAuth redirect to your node app and then you’d redirect to the video platform.

This is generally done by using the domain configuration. For example, all users with an email address domain of acme.com can be configured to use a particular SAML or OpenID Connect configuration.

As soon as you configure one IdP with a domain, the login panel will collect the email address first to understand if we need to ask for a password or forward them along to a federated identity provider.

Read more about managed domains here: https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/