authn context comparison per relying party

[Michael Grady]

I'd say there are multiple problems with this, both the Salesforce side and, if you use Duo, on the Duo side. If you read thru the Salesforce docs, you will see they accept 'pop' as an indication of non-phishable MFA, but Duo includes that for standard Duo push, which I don't think many would argue is non-phishable. It certainly does not match the description that Salesforce provides for non-phishable, versus the table of values they accept to indicate such.

And good luck getting Salesforce to accept the REFEDS MFA value, they will simply do a substring search of what you return and, as you say, consider that you sent the 'mfa' value. 

One "don't fight the vendor" option you have, if you consider all your MFA to be non-phishable, is simple define a new ACR that matches one of the ACR values Salesforce accepts for non-phishable. Associate that as another ACR that the MFA flow and your MFA-specific (e.g. DuoOIDC) flows satisfy, and add a relying party override for your Salesforce entityIDs saying they need that ACR.

Now if the MFA methods you allow are mixed and include both phishable and non-phishable, then the solution becomes slightly more complex, where you need to look at values returned from the MFA vendor and decide if it was non-phishable or not -- depending on how you interpret the Salesforce document(s) on this, and how you choose to interpret what the MFA vendor returns.

> On Aug 24, 2026, at 11:24 AM, Bobby Lawrence via users <users at shibboleth.net> wrote:
> 
> We have a Salesforce instance which is using our IdP for authentication.  Salesforce has recently implemented a requirement that admins login with a phishing-resistant MFA method.  Our IdP is asserting "https://refeds.org/profile/mfa".  Per REFEDs, that should be enough as its definition is "an additional, higher authentication strength, Phishing-Resistant MFA, that protects against adversary-in-the-middle and related phishing attacks."
> For whatever reason, Salesforce asserts this as standard "mfa" and not phishing resistant.  This is likely a bug they need to fix but in the meantime, we have admins who cannot log in.
> I feel like I need to adjust the "shibboleth.AuthenticationPrincipalWeightMap" bean to make this work but I dont see a way to do this for a specific relying party.  I do see that the SAML2.SSO bean exposes a "authnContextTranslationStrategy" option to use a custom function for determining the authn context.  Will this do what I need it to do?
> -- 
> For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


--
Michael A. Grady
IAM Architect, Unicon, Inc.