IDPv3.3 and programmatically selecting MFA based on attribute

[Ho, PeiQuan]

Would it be possible to include in the documentation also which files to make the changes in item 1?

I believe this portion is declared somewhere in conf/authn/general-authn.xml

<bean id="MfaPrincipal" parent="shibboleth.SAML2AuthnContextClassRef"
  c:classRef="https://refeds.org/profile/mfa" />
 
<bean id="PasswordPrincipal" parent="shibboleth.SAML2AuthnContextClassRef"
  c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />

And conf/relying-party.xml has something like this in the shibboleth.RelyingPartyOverrides section

<bean parent="RelyingPartyByTag">
    <constructor-arg name="candidates">
        <list>
            <bean parent="TagCandidate" c:name="http://macedir.org/entity-category"
                p:values="http://example.org/mfa-candidate"/>
        </list>
    </constructor-arg>
    <property name="profileConfigurations">
     <list>
       <bean parent="SAML2.SSO" p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT>
         <property name="defaultAuthenticationMethods">
           <list>
             <ref bean="MfaPrincipal" />
             <ref bean="PasswordPrincipal" />
           </list>
          </property>
        </bean>
      </list>
    </property>
</bean>

Thanks,
-PQ

-----Original Message-----
From: Scott Koranda [mailto:skoranda at gmail.com] 
Sent: Thursday, March 23, 2017 3:51 PM
To: Shib Users <users at shibboleth.net>; Ho, PeiQuan <PeiQuan.Ho at tufts.edu>
Subject: Re: IDPv3.3 and programmatically selecting MFA based on attribute

> > One thing I noticed is the first login to an SP, the MFA runs the 
> > first factor (Password), then check the second factor (Duo) as shown 
> > in Log 1 below.  But then, when I SSO to another SP, it seems like 
> > the MFA flows are not actually run at all, but just checks what's in 
> > the cache.  This is shown in Log 2 below.
> 
> Yes, because the IdP is doing the checking, and that's independent of 
> the MFA feature. The ability to prevent that was added for a future 
> release, and Scott Koranda proposed and I believe documented a 
> workaround for cases now where it's a requirement that the MFA logic 
> always run.

You are being generous Scott. 

You proposed the workaround and I just happened to be working on a MFA flow script at the time and was able to verify that your proposal solved my use case. We collaborated on the documentation.

The OP can find the relevant documentation on this wiki page

https://wiki.shibboleth.net/confluence/display/IDP30/MultiFactorAuthnConfiguration

in the sub-section entitled "Reuse of the Entire authn/MFA Flow Result (When Is a MFA Next Flow Strategy Executed?)"

There are two actions numbered 1. and 2. you have to take. The documentation for action 1 includes an example. Don't overlook action
2 (it hides a bit under the example when the source is expanded).

Cheers,

Scott K