MFA Resources

[Jeremiah Garmatter]

Scott,

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.
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:

        <bean parent="RelyingPartyByName" c:relyingPartyIds="ID-Here">
>             <property name="profileConfigurations">
>                 <list>
>                     <bean parent="SAML2.SSO"
> p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:persistent"
> />
>                 </list>
>             </property>
>         </bean>
>

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.

I looked through the relying party configuration documents here:
https://wiki.shibboleth.net/confluence/display/IDP4/RelyingPartyConfiguration
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?

-Jeremiah Garmatter, Systems Administrator
-Ohio Northern University, Class of 2020
-j-garmatter at onu.edu


On Mon, Jul 27, 2020 at 2:32 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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.
>
> The MFA documentation is separate and is the part that combines factors.
>
> https://wiki.shibboleth.net/confluence/display/IDP4/MultiFactorAuthnConfiguration
>
> It is extremely complex because it's just a scripting engine.
>
> 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.
>
> > I'm most interested in what needs to be configured to allow multi-factor
> authentication through DUO and if that can be
> > limited to specific services through some sort of multi-factor policy
> the way that CAS allows.
>
> 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.
>
> 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.
>
> 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).
>
> 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.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200727/7131a709/attachment.htm>