<div dir="ltr"><div>Scott,</div><div><br></div><div>Thank you for the quick reply, your tips on the general-authn.xml script to combine factors was very helpful and I believe I configured it to properly merge the password and duo auths.</div><div>I'm still confused about the services though. I looked into the relying-parties.xml and found that my predecessors included some profile configurations for most of the services. An example of one is included:</div><div><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> <bean parent="RelyingPartyByName" c:relyingPartyIds="ID-Here"><br> <property name="profileConfigurations"><br> <list><br> <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:persistent" /><br> </list><br> </property><br> </bean></div></blockquote><div><br></div><div>Also, I'd like to mention that this system was running shibboleth 3.1 a few days ago before I went through the process of upgrading to 4, not sure if that matters much with these configurations.</div><div><br></div><div>I looked through the relying party configuration documents here: <a href="https://wiki.shibboleth.net/confluence/display/IDP4/RelyingPartyConfiguration">https://wiki.shibboleth.net/confluence/display/IDP4/RelyingPartyConfiguration</a> as well as my relying-parties.xml and found no reference to the defaultAuthenticationMethods or
AuthnContextClassRef in any of them. Would I simply have to create a new bean with the parent=shibboleth.SAML2AuthnContextClassRef passing in a class reference to my mfa method within the profileConfigurations property?<br></div><div><br> </div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">-Jeremiah Garmatter, Systems Administrator<br></div><div>-Ohio Northern University, Class of 2020<br></div><div>-<a href="mailto:j-garmatter@onu.edu" target="_blank">j-garmatter@onu.edu</a></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 27, 2020 at 2:32 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</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">The docs on Duo are not the story of configuring MFA, they're just the mechanical bits of the Duo integration, which amounts to "set the Duo integration properties in a file" for most people.<br>
<br>
The MFA documentation is separate and is the part that combines factors.<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP4/MultiFactorAuthnConfiguration" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP4/MultiFactorAuthnConfiguration</a><br>
<br>
It is extremely complex because it's just a scripting engine.<br>
<br>
The default configuration file for it is already an example of how to combine two factors in a simple way, and deploying password + duo amounts to using that example, modulo s/IPAddress/Password and s/Password/Duo in the script. The example chains IPAddress followed by Password, so it just has to be updated to chain Password and Duo.<br>
<br>
> I'm most interested in what needs to be configured to allow multi-factor authentication through DUO and if that can be<br>
> limited to specific services through some sort of multi-factor policy the way that CAS allows.<br>
<br>
Limiting by services is governed by understanding the custom Principal mechanism that the whole authentication system is built around, and how the IdP derives requirements on the request side and marries it to capability on the configuration side.<br>
<br>
Services are associated with a set of required Principal objects that are configured, if you hardcode them, by setting the defaultAuthenticationMethods property in relying-party.xml with the requested types. In SAML terms, these are the AuthnContextClassRef strings that are fundamental to controlling authentication in the protocol.<br>
<br>
The supportedPrincipals properties in general-authn.xml determine in turn what each method supports. It can also be more dynamic then that, but for simplicity, I'm assuming it's static (Password means X, Y, Z, Duo means A, B, C).<br>
<br>
The IdP and, in the MFA example, the scripted calls to isAcceptable() produce a runtime evaluation that tells the system whether it has to do perform the second factor. If the first factor isAcceptable() then it knows not to.<br>
<br>
-- Scott<br>
<br>
<br>
-- <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>