<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Just an update to this.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
I got a little lucky here because of 2 main things:</div>
<ol start="1" data-editing-info="{"applyListStyleFromLevel":false,"orderedStyleType":3}" style="margin-top: 0px; margin-bottom: 0px;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); margin-top: 0px; margin-bottom: 0px; list-style-type: "1) ";">
<div class="elementToProof" role="presentation">the Salesforce SAML single sign-on settings do not allow configuration of a specific ACR so none is being sent in the AuthnRequest</div>
</li></ol>
<ol start="1" data-editing-info="{"applyListStyleFromLevel":false,"orderedStyleType":3}" style="margin-top: 0px; margin-bottom: 0px;">
<li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); list-style-type: "1) ";">
<div class="elementToProof" role="presentation">all of the Salesforce users at our organization have smart cards</div>
</li></ol>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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'.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b> users <users-bounces@shibboleth.net> on behalf of Scott Cantor via users <users@shibboleth.net><br>
<b>Sent:</b> Monday, August 24, 2026 1:42 PM<br>
<b>To:</b> Shib Users <users@shibboleth.net><br>
<b>Cc:</b> Scott Cantor <scott@restingparrotsoftware.com><br>
<b>Subject:</b> [EXTERNAL] Re: authn context comparison per relying party </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Scott<br>
<br>
--<br>
For Consortium Member technical support, see <a href="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=" id="OWA7dc361fa-5636-6cde-b021-c6875bab7242" class="OWAAutoLink" data-auth="NotApplicable">
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=</a><br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br>
</div>
</body>
</html>