Accessing SAML request requirements in a MFA transition strategy

[Guillaume Rousse]

Hello.

We're using the MFA authentication flow, and we're trying to mix 
SP-driven and IdP-driven decisions for second factor usage, using a 
strategy, as documented here:
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505534/MultiFactorAuthnConfiguration#Programmatically-Selecting-Flows

The example on this page, as well of other sources of inspiration, 
honours explicit SP requests for MFA, otherwise fall back to IdP-driven 
decision:

authCtx  = 
input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
mfaCtx   = 
authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");

if (!mfaCtx.isAcceptable()) {
   // SP-driven decision: MFA requested, let's use second factor
} else {
   // IdP-driven decision: let's check if second factor is required
}

However, this doesn't handle the case of an SP explicitely requiring to 
not use MFA. We do have at least one use case for this: our 
second-factor management solution, which can't use MFA as long as no 
second factor have been configured.

We could handle this specific case using an hard-coded list of 
exceptions, such as:

entity = 
input.getSubcontext("net.shibboleth.profile.context.RelyingPartyContext").getRelyingPartyId();

if (entity == "exception1") {
   // SP-driven decision
   if (mfaCtx.isAcceptable()) {
      // MFA not requested, let's stop here
   } else {
      // MFA requested, let's use second factor
   }
} else {
   // IdP-driven decision
}

However, this could quicly grows ouf of control if the list of use cases 
grows. I'd rather base the decision on the presence of an explicit 
authnContext in the SAML authnRequest, ie:

if (SAML request requires an explicit authnContext) {
   // SP-driven decision
} else {
   // IdP-driven decision
}

This seems more maintainable in the long term, but I couldn't figure how 
to achieve this, just by reading API documentation :(

Any hint welcome.
-- 
Guillaume Rousse
Direction des Services Applicatifs
RENATER - Paris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20251118/c54d47f4/attachment.p7s>