github relying party & MFA

[Cantor, Scott]

RelyingParty rules are best handled with relying-party.xml overrides carrying the defaultAuthenticationMethods property and whatever custom AuthnContextClassRefPrincipal(s) are required to trigger other factors. That's shown in various examples.

Using overrides are good for lots of reasons, but mainly because there are so many ways now they can be applied, and because the configuration is reloadable when it needs to be changed.

MFA logic should always focus on the isAcceptable() method to determine whether to apply additional factors:

                nextFlow = "authn/Duo";

                // Check if second factor is necessary for request to be satisfied.
                authCtx = input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
                mfaCtx = authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
                if (mfaCtx.isAcceptable()) {
                    nextFlow = null;
                }
                
                nextFlow;   // pass control to second factor or end with the first
 
Rules based on user attributes are the exception that contaminates all the logic because they mess with the simple rules that should already be in place from SPs either requesting something or having it applied to them in relying-party.xml.

Anything is possible, and everything becomes inherently complex once there's a hint of user-driven logic involved.

The problem with just bypassing MFA for users is that if the SP asked for it, you do not have the right under the standard to ignore that. You can only implement a bypass for SPs that you yourself have imposed the requirement for internally since you're just altering the logic that ultimately imposes that requirement.

-- Scott