...
Communicating Change in AuthN Context to SPs
When the IdP is authenticating in bypass/fail-open mode, what should be sent to SPs indicating that the AuthN context is different?
There are really two circumstances here:two basic scenarios in which this question might be asked:.
SP requests/validates and IdP communicates MFA success
In this case, the SP explicitly requests MFA or (or the equivalent) through the requested authentication context(s). The IdP then 1) The IdP explicitly communicates the fact of Duo (or any other MF) authentication success through a separate AuthN context.
In this case, the IdP should not The IdP must not (per SAML standards) assert Duo/MFA success when if authentication is done via "fail-open", so if MFA fails, the SP authentication process will fail ("cannot authenticate using MFA") or be modified ("authenticated with password only"). Note that using approved alternatives to a primary MFA mode is not necessarily the same as "fail-open". E.g., if Duo push fails, but Duo authentication can be performed with other mechanisms (texting a code, use of a one-time code, etc.), it would still be acceptable for the IdP to indicate MFA success.
SPs explicitly requesting/consuming MFA contexts therefore need to either accept downtime when MFA systems fail (because MFA success cannot be asserted) or must be configured to allow for password-only authentication under appropriate circumstances. (E.g., the SP could be easily reconfigured reconfigurable to allow for "Password Protected Transport" logins in the event of an MFA failure event).
IdP locally (and silently) enforces MFA
In this case the IdP uses 2) The IdP enforces MFA based on local criteria (not based on specific requests from the SP) and to decide whether to authenticate the user using MFA (e.g., flags on the user object in the IDM system). Typically in this case the IdP does not communicate the fact of MFA In this to the SP, instead indicating simply success of a "Password Protected Transport" login. Some mechanisms for allowing "fail-open" behavior are described in the preceeding sections ("Bypassing Duo")
Here the SP is not able (or presumably interested in) to determine whether authentication success implies that MFA actually occurred case the SP is presumably not invested in the success of the MFA, and the IdP can indicate authenticate authentication success if "fail-open" occurs, presuming that this is consistent with the IdP's operating practices. Pragmatically, if SPs are relying on IdP-enforced MFA support for increased security it is advisable to communicate this behavior (of defaulting to "fail-open" or "fail-closed") to ensure that they are aware of the impacts. That is, if the SP operator knows the IdP operator is enforcing MFA, but the fact of MFA is not communicated explicitly in the SAML assertion to the SP, then whether or not "fail-open" success is allowable is effectively a business/SLA form of decision.
If the IdP supports "fail-open" operation, then SPs that do not wish to support have authentication success in a "fail-open" can be handled on an exception mode would need to be addressed on a case-by-case basis or, preferably, be reconfigured to explicitly request MFA support so that they can make the determination of whether MFA was successful themselves.
Configuring an SP to request/validate two factor
...
.
...