Login not possible if user has authenticated with another system.

@Grienauer, can you provide more details on this solution you found?

What does the Microsoft app URL mean exactly? I am seeing similar issue with users who simply changed MFA providers.

I have not worked with a MS IdP before, so I'm just guessing + adding an own question/suggestion.

I don't know what the "Microsoft app URL" is; my guess from interpreting the above is that there are (in @Grienauer's situation)

• the actual IdP, which cannot ask for a password (or, at least not when the user is already logged in?)
• some "app" (registered in the portal.azure.com dashboard???) which will forward the user to the IdP if necessary, and immediately bounce back to the SP/Drupal site if already logged in./li>

...and it is the 2nd thing that should be registered as "Single Sign On Service" URL in this module's settings. Maybe.

But -- as for the alternative discussed in the original message:

To solve this the RequestedAuthnContext coud be removed or a "„fresh Authentication" could be added to the request.

@shrop, if this is still an issue, can you check if the "Specify authentication context" checkbox is disabled, and if not: disable it and see if this has any effect on the login error?

This may be the last remaining SAML option that is not well documented in this module / has been unchanged since v8.x-1.0. AFAIK the default behavior (checkbox enabled) tells the IdP that the user should authenticate specifically with a "password" mechanism. There are in theory many more mechanisms that can be specified... but I have not heard yet from anyone needing to do this, so have not been able to test.

Just noting here, we ran into this error:

Authentication method 'MultiFactor, PasswordlessPhoneSignIn' by which the user authenticated with the service doesn't match requested authentication method 'Password, ProtectedTransport'

Disabling the "Specify authentication context" option as outlined above resolved the issue.

See https://github.com/SAML-Toolkits/php-saml README:

// Authentication context.
// Set to false and no AuthContext will be sent in the AuthNRequest.
// Set true or don't present this parameter and you will get an AuthContext 'exact' 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport'.
// Set an array with the possible auth context values: array ('urn:oasis:names:tc:SAML:2.0:ac:classes:Password', 'urn:oasis:names:tc:SAML:2.0:ac:classes:X509').
'requestedAuthnContext' => false,

Thank you for the report. This feedback (confirms my thoughts from the previous comment and) makes me think about necessary next steps.

I'll close this issue though, because (though the last comment does correctly answer my previous comment) it's not clear from the initial issue description, what should be done here.

I've added a section to the bottom of the README that describes the issue and current situation / possible followup. If anyone does want to implement the followup, that wlll likely be better off as a new issue.