Issues with Passkey logins via Entra in SAML proxy mode.

[Chris Groves]

We've hit this recently too with the wider push of passkeys in Entra.
Only one SP found so far, which in their request has the following:

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

I think the issue being Entra only allows a comparison of "exact" or leaving the comparison property out completely. Shibboleth is behaving exactly as designed and is proxying the request to Entra. Entra is where the issue lies.

As it's only one SP for us in a 1-2-1 relationship, we're asking if they can remove the Comparison. Any more come up and it might get interesting.

Chris.


________________________________
From: users <users-bounces at shibboleth.net> on behalf of Mark Cairney via users <users at shibboleth.net>
Sent: Monday, August 03, 2026 13:16
To: Shib Users <users at shibboleth.net>
Cc: Mark Cairney <Mark.Cairney at ed.ac.uk>
Subject: Issues with Passkey logins via Entra in SAML proxy mode.

External email to Cardiff University - Take care when replying/opening attachments or links.
Nid ebost mewnol o Brifysgol Caerdydd yw hwn - Cymerwch ofal wrth ateb/agor atodiadau neu ddolenni.



Hi,

We've had reports of issues logging into services protected by our
Shibboleth IdP when using alternative authn methods like Passkeys from
Entra in SAML proxy mode.

The error in Entra is 'Authentication method 'MultiFactor,Fido' by which
the user authenticated with the service doesn't match requested
authentication method 'Password, ProtectedTransport'. Contact the
Shibboleth-Live application owner.'

Unfortunately I don't see any obvious error logs in the Shibboleth IdP
side which suggests the issue is between the Entra IdP and the
Shibboleth IdP (in SP mode).


I've seen some documentation e.g.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fspaces%2FKB%2Fpages%2F3503587329%2FSupporting%2Bthe%2BREFEDS%2BMFA%2BProfile%2BV5&data=05%7C02%7Cgrovescd%40cardiff.ac.uk%7Cb28af5cf4add42fcb40f08def159194d%7Cbdb74b3095684856bdbf06759778fcbc%7C1%7C0%7C639213562142482841%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hfZmSWJ8qa2FVJDF3qDIJkDYnN%2FmWUIQzn4xnZyQQ%2Bs%3D&reserved=0<https://shibboleth.atlassian.net/wiki/spaces/KB/pages/3503587329/Supporting+the+REFEDS+MFA+Profile+V5>
refer to the idp.authn.MFA.supportedPrincipals key but from what I can
tell that is only applicable if you're using the MFA login flow not the
SAML login flow used in SAML proxy mode.


Has anyone else seen this behaviour? While we're not seeing a huge
number of issues being reported because of this (and we have a
workaround i.e. use traditional password + MFA to login) I'm slightly
concerned we might see more and more issues like this as these
alternative authn methods become more popular and recommended.


Kind regards,

Mark



--
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk

*******************************/

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

--
For Consortium Member technical support, see https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C02%7Cgrovescd%40cardiff.ac.uk%7Cb28af5cf4add42fcb40f08def159194d%7Cbdb74b3095684856bdbf06759778fcbc%7C1%7C0%7C639213562142533533%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pswd34ytLnTVmXu9SNSusW77LHPUnDlSUbbMBeUAkQI%3D&reserved=0<https://shibboleth.atlassian.net/wiki/x/ZYEpPw>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260803/0ff1f6d7/attachment.htm>