Default Authentication Flow + MFA

[Klingenstein, Nate]

> That's insane,

I just get the requirements passed down.  It's not my preference, I promise.  You should see the other projects.

> but you're better off explicitly setting a defaultAuthenticationMethod value in every case to trigger the second, and I guess you'll have to define something that has to be requested or set in defaultAuthenticationMethod to trigger the first in the special cases.

I -think- I did that:

    <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">
				  <property name="defaultAuthenticationMethods">
				    <list>
						<bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
					</list>
				  </property>
			  </bean>
				<ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <ref bean="SAML2.AttributeQuery" />
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>

> Of course the supportedPrincipal collections had better not overlap or none of this is going to work well.

And that:

	<bean id="authn/Password" parent="shibboleth.AuthenticationFlow"
		p:passiveAuthenticationSupported="true"
		p:forcedAuthenticationSupported="true">
		<property name="supportedPrincipals">
			<list>
				<bean parent="shibboleth.SAML2AuthnContextClassRef"
					c:classRef="https://idp-co.calstate.edu/formsAuth" />
			</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="https://iam.calstate.edu/csuconnect/mfa" />
                    <bean parent="shibboleth.SAML2AuthnContextClassRef"
                        c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
                </list>
            </property>
        </bean>

What I didn't do was add urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport as a supported principal for the authn/RemoteUser bean.

> No, and it doesn't matter if you do what I suggested, but it means it picks a flow that's enabled and tries it. Nominally in the order they're laid out in the general-authn list.

That's what I thought; it looked like a response only thing.

> As long as you do what I suggested, leave Password alone as one method and script RemoteUser + Duo inside MFA for the other. As long as they're entirely independent it's just like doing two separate set ups that are fairly simple on their own.

Okay.