<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-CA link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Jeffrey..<o:p></o:p></p><p class=MsoNormal>Thanks for the feedback on the KB article!<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One way to look at the MFA approach is that *<b>all</b>* accounts from Azure AD require MFA to go through the Shib IdP Proxy. Therefore, all accounts are MFA by default. If this is true for your Azure tenant, you can work on attesting an AuthNContext as REFEDS MFA. I don’t have precise settings for that for the KB article however. If you go this route, let me know and will work it into the article..<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>While it sounds like an easy win, it only works for 100% MFA coverage -- or at least 100% coverage of the _<i>users</i>_ through that proxy instance – ie an MFA only IdP. I cringe more than a bit though – it doesn’t scale well and may not be very palatable (or allowed?) for the same scopes inside a given federation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott’s comments about using the technique in v4.1 is, to me, the best pathway to pursue. <o:p></o:p></p><p class=MsoNormal>It can handle a diverse account base of both MFA and non MFA accounts status and is something for the next iteration of that KB article that we’re early days on working through the step by step recipe..<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>All that said, if Services command (REFEDS) MFA be used for sign on, it should be that transaction and every time it’s asked for. If it isn’t offered, the transaction should fail-secure. Fail-secure means the user sign on should not achieve sufficiency for MFA but Single Factor Authentication (SFA), password transport, or simply not logon. This has nothing to do with Shibboleth and everything to do with practices on and around MFA usage and policies in front of or upstream of the IdP itself like in the proxy case.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Services commanding MFA expect it each and every time, not sometime in the last 30 days, the last 7 days, or even in the last 48hrs. They expect it for that sign on. I strongly encourage disabling/ignoring these ‘remember the token’ abilities as it’s not really truthful to the Service for MFA if those policies are in effect and applied. This will feel painful but when MFA is asked for the consequences are too high to fudge this aspect.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Chris.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'>"users-bounces@shibboleth.net" <users-bounces@shibboleth.net> on behalf of SHIB-USERS <users@shibboleth.net><br><b>Reply-To: </b>SHIB-USERS <users@shibboleth.net><br><b>Date: </b>Friday, January 22, 2021 at 5:03 PM<br><b>To: </b>SHIB-USERS <users@shibboleth.net><br><b>Cc: </b>Jeffrey Williams <jfwillia@uncg.edu><br><b>Subject: </b>Shib Authn Proxy to Azure and Asserting REFEDS<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi All,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm trying to configure Shibboelth v4.0.1 to assert <a href="https://refeds.org/profile/mfa">https://refeds.org/profile/mfa</a> after a user MFA's via proxy to Azure and am running into some interesting questions.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have a semi-working instance of running in development that is doing proxying to Azure using the instructions given at:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><a href="https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD">https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>(note, some additional work to the Azure metadata and subject-c14n.xml were needed, but not much)<br><br>The issue I'm currently dealing with is that Azure AD doesn't have it clearly documented what AuthnContexts <a href="https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-saml-tokens#claims-in-saml-tokens:~:text=authenticated.-,%3CAuthnContextClassRef%3E,%3C%2FAuthnContextClassRef%3E">one can request from it aside from</a> <span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#171717'><br></span><code><span style='font-size:9.0pt;font-family:Consolas;color:#171717'><a href="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod/password">http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod/password</a></span></code><span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:#171717'><br></span><br>What Azure seems to do instead is return the above AuthnContext and include an attribute <a href="http://schemas.microsoft.com/claims/authnmethodsreferences">http://schemas.microsoft.com/claims/authnmethodsreferences</a> which returns the various authn's the user performed. <br><br>The example code in authn-comparison.xml seems to indicate that it'll happily convert between AuthnContexts using shibboleth.<a href="https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration#AuthenticationConfiguration-AuthenticationTypeMapping:~:text=shibboleth.PrincipalProxyResponseMappings">PrincipalProxyResponseMapping</a>s. Will it also allow AuthnContextClassRef to be influenced by a value returned in the attribute statement?<br><br>For example, if within the AttributeStatement, an attribute <a href="http://schemas.microsoft.com/claims/authnmethodsreferences">http://schemas.microsoft.com/claims/authnmethodsreferences</a> contained a value <a href="http://schemas.microsoft.com/claims/multipleauthn">http://schemas.microsoft.com/claims/multipleauthn</a>, could one map that to a <a href="https://refeds.org/profile/mfa">https://refeds.org/profile/mfa</a> authnContextClassRef in the AuthnStatement? Or is the mapping more simple than that?<br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If that's not possible, would it be possible to run a script after the authn/SAML flow that would do the attribute check and update the AuthnContext accordingly? I've done scripting for determining when to present the Duo iFrame, but I'm not sure if it's possible to replace the AuthnContextClassRef value from a script or not. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks!<o:p></o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal>Jeffrey Williams <o:p></o:p></p></div><div><p class=MsoNormal>Identity & Access Engineer<br>Identity & Access Services<br><a href="https://its.uncg.edu" target="_blank">https://its.uncg.edu</a><o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='border:solid windowtext 1.0pt;padding:0cm'><img border=0 width=32 height=32 style='width:.3333in;height:.3333in' id="_x0000_i1025" src="cid:~WRD0002.jpg" alt="Image removed by sender."></span><o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></body></html>