MFA Resources

Tue Jul 28 17:59:45 UTC 2020

On 7/27/20, 8:49 PM, "users on behalf of Jeremiah Garmatter" <users-bounces at shibboleth.net on behalf of j-garmatter at onu.edu> wrote:

> I thought I could use Stanford Universities MFA context

That's between you and Stanford, but there's basically one standard in academia, or you define your own. I use a URI I defined for my use on campus.

The REFEDS value is defined in https://refeds.org/profile/mfa and may be fine if the deployment meets its minimal requirements. OSU's deployment right now does not meet it, therefore I couldn't use it, and had to invent one.

> I will reiterate that I have little experience with Java and xml and no experience with the Spring WebFlow.

    Should I be configuring some sort of script within the mfa-authn-config.xml script? Prior to this upgrade we were running shibboleth 3.1.2, which didn't even support multifactor from what I understand, so I'm not sure how mfa factors in to this whole situation. We only needed username and password authentication at that time. This single-factor authentication still works after the upgrade to shibboleth 4.0. Am I supposed to configure MFA to override the single factor username to allow for multiple forms of authentication? I have no Idea how this works and while reading the shibboleth documentation I find myself more confused than when I started. 

    How does the ProfileConfiguration-Authentication link provided in the last email fit in with the relying-party.xml configuration I have in (2)? If I try to define the default auth method for a specific service provider, I was able to sign in to the service with only my username and password (no Duo enrollment or prompt) or I was met with another generic "relying-party.xml misconfiguration" error.

    All I want is to sign in to one particular service provider with username and password, then be prompted to authenticate through Duo, and be brought back to my service if all goes well. I apologize for being so brash, but I don't have the time to become a spring developer and those who set this system up have left my place of business, taking their experience with them.

    As usual, help is appreciated, but if what I ask is beyond the scope of this email list please refer me to another group.

    (1.)general-authn.xml:
    <bean id="authn/Duo" parent="shibboleth.AuthenticationFlow"
                    p:forcedAuthenticationSupported="true"
                    p:nonBrowserSupported="false">
                <!--
                The list below should be changed to reflect whatever locally- or
                community-defined values are appropriate to represent MFA. It is
                strongly advised that the value not be specific to Duo or any
                particular technology.
                -->
                <property name="supportedPrincipals">
                    <list>
                        <bean parent="shibboleth.SAML2AuthnContextClassRef"
                            c:classRef="http://example.org/ac/classes/mfa <https://urldefense.com/v3/__http://example.org/ac/classes/mfa__;!!KGKeukY!jJYu4V_FTk37XDWoxTzFIWPu1MBZ6O4d-MSI3hyqAhTfrDDFlBVFXk7MILMfBD0$>" />
                        <bean parent="shibboleth.SAML1AuthenticationMethod"
                            c:method="http://example.org/ac/classes/mfa <https://urldefense.com/v3/__http://example.org/ac/classes/mfa__;!!KGKeukY!jJYu4V_FTk37XDWoxTzFIWPu1MBZ6O4d-MSI3hyqAhTfrDDFlBVFXk7MILMfBD0$>" />
                    </list>
                </property>
            </bean>

            <bean id="authn/MFA" parent="shibboleth.AuthenticationFlow"
                    p:passiveAuthenticationSupported="true"
                    p:forcedAuthenticationSupported="true">
                <!--
                The list below almost certainly requires changes, and should generally be the
                union of any of the separate factors you combine in your particular MFA flow
                rules. The example corresponds to the example in mfa-authn-config.xml that
                combines IPAddress with Password.
                -->
                <property name="supportedPrincipals">
                    <list>
                        <bean parent="shibboleth.SAML2AuthnContextClassRef"
                            c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol" />
                        <bean parent="shibboleth.SAML2AuthnContextClassRef"
                            c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
                        <bean parent="shibboleth.SAML2AuthnContextClassRef"
                            c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
                        <bean parent="shibboleth.SAML1AuthenticationMethod"
                            c:method="urn:oasis:names:tc:SAML:1.0:am:password" />
                    </list>
                </property>
            </bean>

    (2.) relying-party.xml:
    <!--
        Default configuration, with default settings applied for all profiles, and enables
        the attribute-release consent flow.
        -->
        <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
            <property name="profileConfigurations">
                <list>
                    <bean parent="Shibboleth.SSO" />
                    <ref bean="SAML1.AttributeQuery" />
                    <ref bean="SAML1.ArtifactResolution" />
                    <bean parent="SAML2.SSO" />
                    <ref bean="SAML2.ECP" />
                    <ref bean="SAML2.Logout" />
                    <ref bean="SAML2.AttributeQuery" />
                    <ref bean="SAML2.ArtifactResolution" />
                </list>
            </property>
        </bean>

            <bean parent="RelyingPartyByName" c:relyingPartyIds="SP's Entity-ID">
                <property name="profileConfigurations">
                    <list>
                        <bean parent="Shibboleth.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
                        <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
                    </list>
                </property>
            </bean>

    -Jeremiah Garmatter, Systems Administrator

    -Ohio Northern University, Class of 2020

    -j-garmatter at onu.edu

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

    On 7/27/20, 3:43 PM, "users on behalf of Jeremiah Garmatter" <users-bounces at shibboleth.net on behalf of j-garmatter at onu.edu> wrote:

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

    The SAML2.SSO bean has a lot of other settings. One of them is defaultAuthenticationMethods. All the profiles that involve a user logging in have that property.

    https://wiki.shibboleth.net/confluence/display/IDP4/ProfileConfiguration-Authentication <https://urldefense.com/v3/__https://wiki.shibboleth.net/confluence/display/IDP4/ProfileConfiguration-Authentication__;!!KGKeukY!jJYu4V_FTk37XDWoxTzFIWPu1MBZ6O4d-MSI3hyqAhTfrDDFlBVFXk7MbE-GC_0$>

    Second example is what you're asking about.

    > 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?

    Sort of, but the example includes the right syntax (or one syntax among a dozen that are equivalent in Spring).

    -- Scott

    -- 
    For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg <https://urldefense.com/v3/__https://wiki.shibboleth.net/confluence/x/coFAAg__;!!KGKeukY!jJYu4V_FTk37XDWoxTzFIWPu1MBZ6O4d-MSI3hyqAhTfrDDFlBVFXk7MOxZvuuA$>
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net