[EXTERNAL] Re: authn context comparison per relying party

[Bobby Lawrence]

Just an update to this.
I got a little lucky here because of 2 main things:

  1.
the Salesforce SAML single sign-on settings do not allow configuration of a specific ACR so none is being sent in the AuthnRequest

  1.
all of the Salesforce users at our organization have smart cards

So I fixed this by setting the 'defaultAuthenticationMethods' on the Salesforce relying party override to 'urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard'.

Our IdP is configured to trigger the X509 authentication flow in this case so as long as the user agent is being run on a device that their smart card is plugged in to, the user can simply pick the smart card certificate, enter their pin and the login succeeds.



________________________________
From: users <users-bounces at shibboleth.net> on behalf of Scott Cantor via users <users at shibboleth.net>
Sent: Monday, August 24, 2026 1:42 PM
To: Shib Users <users at shibboleth.net>
Cc: Scott Cantor <scott at restingparrotsoftware.com>
Subject: [EXTERNAL] Re: authn context comparison per relying party

Mike covered the issues well. Salesforce is broken and not compliant with SAML or OpenID in a number of ways without even getting into the question of what PHR even means. It is not allowed to substring match things the way they are doing. it's a hack in the face of them realizing you can't do what they want to do across a set of non-cooperating IdPs.

All I'll say is that with the Shibboleth hat on, the idea is you define additional AC class ref Principals as supported and asserted and then you satisfy different SPs needs with them at the same time. If need be, the weight map will help prioritize them, but it can't create them nor suppress them, you have to implement the configuration you need for that, which in the case of Duo generally means separate integrations that would lead to different Principal sets, much as is demonstrated in the HowTo I wrote around REFEDS MFA usage.

With a REFEDS hat on as a participant in the WG(s), the original REFEDS MFA profile was not meant to be phishing resistant to the level that Salesforce is thinking about and that others have started to coalesce around. There is a second, new REFEDS MFA profile for that that adds a second context class for those cases.

Actually preventing misuse of all those when using Duo? That's out of scope, but it is very non-trivial without having pretty limited rules in place for factors, turning off Remember Me, etc.

We extended the plugin to include some code to help with using their new AMR claim from Duo to help drive production of particular Principals on the Shibboleth IdP end.

-- Scott

--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__shibboleth.atlassian.net_wiki_x_ZYEpPw&d=DwICAg&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bs2UfpzD0fSGcxiXJeDGwtg&m=QGh7tWTr5wmCLEx4adnAkB6NWWG0OLvQ6IRTxEyBjIVVOfWdWIPTBSDDCxtpiJ2e&s=6yNQ_0U-9G2_drS9dmPz0sx2IE2QOh-fKCcoHeg2D1c&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260826/160cb808/attachment.htm>