authn context comparison per relying party

[Mak, Steven]

Bobby,

We ended up solving this by using an alternate method that Salesforce supports - a custom resolved attribute 'salesforceAMR'. This felt like a much better fit than trying to do very weird things with the ACCR.

Here are some snippets we used to setup our system to resolve the attribute:

duo-oidc-authn-config.xml (assuming you are already using custom duo config):

                var ac = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                var reqCtx = input.getSubcontext("net.shibboleth.idp.profile.context.SpringRequestContext").getRequestContext()

                if (ac != null) {
                    var dc = ac.getSubcontext("net.shibboleth.idp.plugin.authn.duo.context.DuoOIDCAuthenticationContext");
                    if (dc != null) {
                        if (dc.getAuthToken() != null) {
                            var duo_factor = dc.getAuthToken().getJWTClaimsSet().getJSONObjectClaim("auth_context").get("factor");

                            // Set conversationScope for SalesforceAMR attribute
                            if (duo_factor == "Some duo factor 1" || duo_factor == "Some duo factor 2") {
                                conversationScope = reqCtx.getConversationScope()
                                conversationScope.put("some_flag_here", true)
                            }
                        }
                    }
                }

resolver.xml

    <AttributeDefinition id="salesforceAMR" xsi:type="ScriptedAttribute">
        <Script><![CDATA[
                reqCtx = profileContext.getSubcontext("net.shibboleth.idp.profile.context.SpringRequestContext").getRequestContext()

                conversationScope = reqCtx.getConversationScope()
                strongMFA = conversationScope.get("some_flag_here")

                if (strongMFA != null && strongMFA) {
                    salesforceAMR.addValue("some_flag_here")
                }
            ]]>
        </Script>
        <AttributeEncoder xsi:type="SAML2String" name="authnmethodsreferences" friendlyName="salesforceAMR" encodeType="false"/>
    </AttributeDefinition>


We didn't trust what acr values Duo was asserting and we couldn't control it so we settled on this solution. We use filter policies to control which salesforce apps receive it. We also ignore the remembered device duo factor because we didn't consider that PHR.

- Steve

From: users <users-bounces at shibboleth.net> on behalf of Bobby Lawrence via users <users at shibboleth.net>
Date: Monday, August 24, 2026 at 12:25 PM
To: Shib Users <users at shibboleth.net>
Cc: Bobby Lawrence <robertl at jlab.org>
Subject: authn context comparison per relying party

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<https://urldefense.com/v3/__https://refeds.org/profile/mfa__;!!IBzWLUs!QE-P80OxryUO_OjJUITbDF_AHq-IaOiczzxKCCEKxpP-dtewt-e9-nc3KmcphnB5kUNNzfrI7gw9PCWw$>".  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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260824/eedec9d0/attachment.htm>