Accessing SAML request requirements in a MFA transition strategy

[Guillaume Rousse]

Le 18/11/2025 à 22:15, Scott Cantor a écrit :
> Hi,
> 
> I want to be clear because of my usual comments about support...I'm responding because RENATER is a member, regardless of the fact that it's on the mailing list. I will be all but unwilling to offer any free help next April once I retire from OSU, so I would encourage members to use the support tools, but I will still be scanning occasionally. Can't promise though; you will get much faster responses from the supported options.
OK, I got the point.
>> 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.
> 
> You already hit on the solution:
> 
>> I'd rather base the decision on the presence of an explicit authnContext in the SAML authnRequest, ie:
> 
> You're already handling that case with the isAcceptable check, that's what it does.
> 
> With the usual Password + Duo scenarios, when SPs request the PasswordProtectedContext AC, that check short circuits calling Duo because the existing Password result already satisfies the SP.
> 
> People actively hate this, but you're basically asking for that exact behavior, and that's what it's designed to do.
> 
> You don't have to use PPT obviously, any context will work provided it's supported and expressed by the Password flow, or whatever your first factor is.
Unless I'm mistaken, the isAcceptable check doesn't make any difference 
between those two situations:
- the SP didn't require any specific auth context, making any current 
response OK
- the SP did require a specific context, but the current response 
already satisfies it

We want to make the distinction, because we want the IdP to force MFA 
usage, but only in the first case. Basically, we need to make some of 
our SPs able to opt-out IdP-enforced MFA usage, instead of the usual 
opt-in scenario... Don't blame me, I'm innocent for this decision :)

Regards.
-- 
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/20251119/90163827/attachment.p7s>