Issue with SPs requesting specific authentication methods when using SAML Proxy with EntraID

[Anselm Herkstroeter]

Hello everyone,

I need help with the following problem:

I have an IdP, configured as a SAML Proxy to an EntraID/Azure AD instance.

One of the SPs authenticating against it is requesting the following 
AuthnContext and the IdP forwards this in it's SAML request to EntraID 
when authenticating against that, as it should.

```
<samlp:RequestedAuthnContext Comparison="exact"> 
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> 
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml:AuthnContextClassRef> 
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Multifactor</saml:AuthnContextClassRef> 
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordlessPhoneSignIn</saml:AuthnContextClassRef> 
</samlp:RequestedAuthnContext>
```

The Problem arises when someone is using a method, other than password 
login for authentication. EntraID only seems to check if the login 
fulfills the "PasswordProtectedTransport" requirement and ignores the 
other options.

In my case, I reproduced the problem by using a yubikey, which resultet 
in the following error message on the EntraID login mask:

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

and I have also seen this error

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


I only have control over the IdP so I concluded, that I somehow have to 
remove these requirements from the SAML request to EntraID, because it 
seemingly can't handle them correctly - but haven't found instructions 
for that in the documentation.

I hope someone can help me with this.


Thank you in advance,

Anselm Herkströter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250220/3e8ac7e5/attachment.htm>