<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 25, 2021 at 12:13 PM Chris Phillips <<a href="mailto:Chris.Phillips@canarie.ca" target="_blank">Chris.Phillips@canarie.ca</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 lang="EN-CA"><div><p class="MsoNormal">Hi Jeffrey..<u></u><u></u></p><p class="MsoNormal">Thanks for the feedback on the KB article!</p></div></div></blockquote><div><br></div><div>No problem!  If it helps, I'm happy to share specifics on what I did that wasn't included.  Robert Bradley at Oxford was also able to clue me into the proxy request and response mappings in authn-comparison.xml, so we can translate MFA requests from the SP into something</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-CA"><div><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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..</p></div></div></blockquote><div><br></div><div>Since MFA has been mandated at the university system level for NC, we will be in the 100% MFA usage scenario.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-CA"><div><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></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.</p></div></div></blockquote><div><br></div><div>Can you elaborate a bit on the scalability issue?  It may be a non-issue for this deployment, but I'm curious.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-CA"><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u><br></p></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-CA"><div><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">"<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>> on behalf of SHIB-USERS <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><br><b>Reply-To: </b>SHIB-USERS <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><br><b>Date: </b>Friday, January 22, 2021 at 5:03 PM<br><b>To: </b>SHIB-USERS <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><br><b>Cc: </b>Jeffrey Williams <<a href="mailto:jfwillia@uncg.edu" target="_blank">jfwillia@uncg.edu</a>><br><b>Subject: </b>Shib Authn Proxy to Azure and Asserting REFEDS<u></u><u></u></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Hi All,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I'm trying to configure Shibboelth v4.0.1 to assert <a href="https://refeds.org/profile/mfa" target="_blank">https://refeds.org/profile/mfa</a> after a user MFA's via proxy to Azure and am running into some interesting questions.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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" target="_blank">https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+in+the+Shibboleth+IdP+to+connect+with+Azure+AD</a><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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" target="_blank">one can request from it aside from</a> <span style="font-size:10.5pt;font-family:"Segoe UI",sans-serif;color:rgb(23,23,23)"><br></span><code><span style="font-size:9pt;font-family:Consolas;color:rgb(23,23,23)"><a href="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod/password" target="_blank">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:rgb(23,23,23)"><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" target="_blank">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" target="_blank">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" target="_blank">http://schemas.microsoft.com/claims/authnmethodsreferences</a> contained a value <a href="http://schemas.microsoft.com/claims/multipleauthn" target="_blank">http://schemas.microsoft.com/claims/multipleauthn</a>, could one map that to a <a href="https://refeds.org/profile/mfa" target="_blank">https://refeds.org/profile/mfa</a> authnContextClassRef in the AuthnStatement? Or is the mapping more simple than that?<br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></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.  <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks!<u></u><u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><div><div><div><div><div><div><div><div><div><p class="MsoNormal">Jeffrey Williams <u></u><u></u></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><u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span style="border:1pt solid windowtext;padding:0cm"><img border="0" width="32" height="32" style="width:0.3333in;height:0.3333in" id="m_-5685488964746197798gmail-m_-3755247044420275610_x0000_i1025" alt="Image removed by sender."></span><u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr">Jeffrey Williams </div><div dir="ltr">Identity & Access Engineer<br>Identity & Access Services<br><a href="https://its.uncg.edu" target="_blank">https://its.uncg.edu</a></div></div><div dir="ltr"><br></div><div dir="ltr"><img src="https://uncgcdn.blob.core.windows.net/email/UNCGLogo.png"><br></div></div></div></div></div></div></div></div></div></div>