<div dir="ltr">Once again, this appears to be a question for Okta, as they should not be (only) returning PasswordProtectedTransport if MFA is in use.<div><br></div><div>You would not want to globally replace that Authentication Context Class with one asserting MFA unless you are positive that the MFA requirement(s) to assert the REFEDS context have been met <u>everytime</u> PasswordProtectedTransport is in the SAML response.<div><br></div><div>There is support included for mapping unique values during the proxy process, intended for use when their responses differ from the values you seek, but still distinct values returned from the proxied IDP. <br><div><br></div><div>Assuming you (or your client) is not attempt to misrepresent the strength of any authentication, you may want to look at the following resources -- these are Azure AD examples, but should be of some help:</div></div><div><a href="https://shibboleth.atlassian.net/wiki/spaces/KB/pages/2783936889/SAML+Proxying+EntraID+Azure+with+the+Shibboleth+IdP#SAMLProxyingEntraID/AzurewiththeShibbolethIdP-ProxyTask6.HandlingREFEDSAuthnContextRequests(optional)">https://shibboleth.atlassian.net/wiki/spaces/KB/pages/2783936889/SAML+Proxying+EntraID+Azure+with+the+Shibboleth+IdP#SAMLProxyingEntraID/AzurewiththeShibbolethIdP-ProxyTask6.HandlingREFEDSAuthnContextRequests(optional)</a></div><div><a href="https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505085/AuthenticationConfiguration#Advanced-Topics">https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505085/AuthenticationConfiguration#Advanced-Topics</a> (Under Proxying)</div><div><br></div><div>Steve.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2024 at 11:28 AM S, Kalidasan via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-3451701536878602396">
<div lang="EN-IN" style="overflow-wrap: break-word;">
<div class="m_-3451701536878602396WordSection1">
<p class="MsoNormal">Hi Team,<br>
<br>
As part of our recent client engagement, we enabled SAML proxy for Shibboleth IDP and configured Okta as upstream IDP.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">In the SAML assertion issued by Shibboleth IDP to the downstream SP applications, we can observe that Okta’s authentication context class “<b>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</b>” is sent as classRef value.
We need to replace this value with “<a href="https://refeds.org/profile/mfa" target="_blank">https://refeds.org/profile/mfa</a>” value in SAML response generated by Shibboleth IDP as before otherwise some of the underlying SPs may fail SSO, considering this as invalid MFA
authentication context class reference<b>(<saml2:AuthnContextClassRef>).</b><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">While exploring the Shibboleth documentations we can find below article talking about
<b>authnContextTranslationStrategy</b> and <b>authnContextTranslationStrategyEx</b>, but there are no proper examples on how to use these with SSO profile and what bean and properties can be used together.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><a href="https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631686/ProfileConfiguration-SAML2SSO" target="_blank">ProfileConfiguration-SAML2SSO - Identity Provider 4 - Confluence</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b><span lang="EN-US">Our version: V4.3.3<u></u><u></u></span></b></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Kindly can you share with us any other Shibboleth documentation or example syntax to achieve the above translation?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks and Regards<br>
Kalidasan S<br>
Advisory - Senior Solution Advisor<br>
<span lang="EN-US">Cyber IAM(Okta) | Deloitte US India Risk and Financial Advisory<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="mailto:kalids@deloitte.com" target="_blank"><span style="color:rgb(5,99,193)">kalids@deloitte.com</span></a> |
<a href="http://www.deloitte.com/" target="_blank"><span style="color:rgb(5,99,193)">www.deloitte.com</span></a></span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p>This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution
of this message, or the taking of any action based on it, by you is strictly prohibited.</p>
<p>Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see <a href="http://www.deloitte.com/about" target="_blank">www.deloitte.com/about</a>
to learn more.</p>
<p>v.E.1</p>
</div>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</div></blockquote></div>