Issues with Passkey logins via Entra in SAML proxy mode.

[Mark Cairney]

Hi,

I initially thought it was happening between the Entra IdP and our Shib 
IdP (acting as an SP) but SAML tracer does indeed tell a different story:

This is the first step in the process which suggests it is indeed the 
third-party SP which is requesting/insisting on :PasswordProtectedTransport

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
ID="ONELOGIN_bbe11677686078bef26075292171eb442766c0a0" Version="2.0" 
IssueInstant="2026-08-03T15:16:15Z" 
Destination="https://idp.ed.ac.uk/idp/profile/SAML2/Redirect/SSO" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
AssertionConsumerServiceURL="https://xerte.cahss.ed.ac.uk/SP/xertelogin.php">
  <saml:Issuer>https://xerte.cahss.ed.ac.uk/SP/entity</saml:Issuer>
  <samlp:NameIDPolicy 
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" 
AllowCreate="true"></samlp:NameIDPolicy>
  <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

And this persists all the way through the SAML conversation:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
ID="ONELOGIN_bbe11677686078bef26075292171eb442766c0a0" Version="2.0" 
IssueInstant="2026-08-03T15:16:15Z" 
Destination="https://idp.ed.ac.uk/idp/profile/SAML2/Redirect/SSO" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
AssertionConsumerServiceURL="https://xerte.cahss.ed.ac.uk/SP/xertelogin.php">
  <saml:Issuer>https://xerte.cahss.ed.ac.uk/SP/entity</saml:Issuer>
  <samlp:NameIDPolicy 
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" 
AllowCreate="true"></samlp:NameIDPolicy>
  <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>


<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" 
AssertionConsumerServiceURL="https://idp.ed.ac.uk/idp/profile/Authn/SAML2/POST/SSO" 
Destination="https://login.microsoftonline.com/2e9f06b0-1669-4589-8789-10a06934dc61/saml2?whr=ed.ac.uk" 
ID="_8b1b9ed7365b9ab2d46bb60e8a910f95" 
IssueInstant="2026-08-03T15:16:16.151Z" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Version="2.0">
  <saml2:Issuer 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.ed.ac.uk/shibboleth</saml2:Issuer>
  <saml2p:NameIDPolicy AllowCreate="true"></saml2p:NameIDPolicy>
  <saml2p:RequestedAuthnContext Comparison="exact">
   <saml2:AuthnContextClassRef 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
  </saml2p:RequestedAuthnContext>
</saml2p:AuthnRequest>

This seems to be a common issue with Onelogin out the box: 
https://github.com/centreon/centreon/issues/5166

and even their sample SAML snippets include this stanza:

https://developers.onelogin.com/saml/examples/authnrequest


Would I be right in suggesting they reconfigure their application to 
either use 'minimum' instead of 'exact' or to simply omit this 
requirement completely?



On 03/08/2026 13:31, Peter Schober via users wrote:
> Mark Cairney via users <users at shibboleth.net> [2026-08-03 14:17 CEST]:
>> 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.'
> Look at the SAML authnRequests (e.g. using the SAML Tracer plugin for
> Firefox or Chromium), what system is requesting those methods? The
> original SP or your SAML IDP proxying to Entra?
>
> (Obviously, no IDP should ever be using password-based authentication
> without TLS, full stop. And no SP should ever be requesting
> "ProtectedTransport" because that's the worst possible authentication
> mechanism used at IDPs in practice.  I.e., the only purpose
> specifically requesting "ProtectedTransport" serves is preventing
> strong/-er authn methods from using used and why would an SP try to do
> that?)
>
> -peter

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

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.