Basic Configuration - CSCfi/shibboleth-idp-authn-storage GitHub Wiki

Current File(s): conf/authn/storage-authn-config.xml, conf/authn/mfa-authn-config.xml, conf/authn/general-authn.xml

Introduction

This page contains configuration examples for a naive MFA case of combining IPAddress and Password authentication and using Storage authentication to "cache" Password authentication.

Applying storage authentication in Shibboleth Multi Factor Authentication.

Multi Factor Authentication is configured to file mfa-authn-config-example.xml. The provided file conf/authn/mfa-authn-config-example.xml contains following simplified snippet.

<util:map id="shibboleth.authn.MFA.TransitionMap">

    <entry key="">
        <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/IPAddress" />
    </entry>

    <entry key="authn/IPAddress">
        <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/storage" />
    </entry>

    <entry key="authn/storage">
        <bean parent="shibboleth.authn.MFA.Transition">
            <property name="nextFlowStrategyMap">
                <map>
                    <!-- If we do not have a storage event we perform password -->
                    <entry key="ReselectFlow" value="authn/Password" />
                </map>
            </property>
        </bean>
    </entry>

    <entry key="authn/Password">
        <bean parent="shibboleth.authn.MFA.Transition" p:nextFlow="authn/store" />
    </entry>

    <!-- An implicit final rule will return whatever the final flow returns. -->
</util:map>

The example mfa authentication performs first IPAddress authentication. Next storage authentication tries to locate a existing result for the user. If result is located, mfa execution ends successfully. If no storage authentications result is found, Password authentication flow is executed. If Password authentication result is success, storage authentication result is stored for the user to be applied in next login.

Note that the components rely on having canonical username available in the phase authn/storage is executed. Also, the flow authn/store relies on having username being resolved prior by authn/storage flow. Therefore execution of the flow authn/storage must always precede executing authn/store.

Declaring storage authentication flows

For MFA flow to use storage authentication flows they need to be declared as available flows in general-auth.xml. Note that the storage authentication flow should match for it's definition the flow it presents the stored result for. The following example is for the Password case we have followed.

<bean id="authn/storage" parent="shibboleth.AuthenticationFlow"
            p:passiveAuthenticationSupported="true"
            p:forcedAuthenticationSupported="true" >
    <property name="supportedPrincipals">
        <list>
          <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>

Note! forcedAuthentication case is not documented yet.

We need to define also the flow that stores the result. It never produces the result so the supported principals is irrelevant.

<bean id="authn/store" parent="shibboleth.AuthenticationFlow"
            p:passiveAuthenticationSupported="true"
            p:forcedAuthenticationSupported="true" />
⚠️ **GitHub.com Fallback** ⚠️