The following page offers advice for planning and handling outages to the Duo Security service.
Choosing an approach – fail-open VS fail-closed – implications of choosing each approach
It's a classic risk/cost balance. The right answer depends on tolerance for risk (in terms of less-secure authentication, as well as loss of the authentication service itself) and what price you're willing to pay.
those applications that must remain protected (HIPPA, FISMA Moderate, in their opinion) remain protected during an incident. However, the much larger (generally speaking) user base of self service and less secure application can continue to operate in an event. This provides a middle of the road solution to protect that which “must” be protected and allow those with lower risk profiles to continue to operate.
Fail-open becomes more defensible as a steady state if the IdP accurately reports the authentication mechanism used. Applications would be able to drop specific assertions or access requests above and beyond the protests of the IAM system, but users that had opted in to two factor wouldn’t be locked out of everything.
A few solutions were offered to support a fail-open integration, to allow AuthN to continue in a weakened state:
I.e., When the IdP is authenticating in bypass/fail-open mode, what should be sent to SPs indicating that the Authentication process that took place didn't include MFA?
There are two basic scenarios in which this question might be asked:.
In this case, the SP explicitly requests MFA or (or the equivalent) through the requested authentication context(s). The IdP then communicates the fact of Duo (or any other MF) authentication success through a separate AuthN context.
The IdP must not (per SAML standards) assert Duo/MFA success 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 or must be configured to allow for password-only authentication under appropriate circumstances. (E.g., the SP could be easily reconfigurable to allow for "Password Protected Transport" logins in the event of an MFA failure event).
In this case the IdP uses local criteria (not based on specific requests from the SP) 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 to the SP, instead indicating simply success of a "Password Protected Transport" login.
Here the SP is not able to (or presumably interested in trying to) determine whether MFA actually occurred as part of the authentication event, and is relying on the IdP to make the appropriate "authentication strength" decision. In this case the IdP can indicate authentication success if "fail-open" occurs, presuming that this is consistent with the IdP's normal operating practices. Pragmatically, if SPs are relying on IdP-managed and -enforced MFA support for increased security it is advisable to document MFA failure behavior (of defaulting to "fail-open" or "fail-closed") to ensure that the SP operators 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 "acceptable" for user authentication is a business/SLA form of decision that cannot be inspected as part of the SAML/authentication conversation.
If the IdP supports "fail-open" operation, then SPs that do not wish to have authentication success in a "fail-open" mode would need to be addressed on a case-by-case basis by the IdP operator or, preferably, be reconfigured to explicitly request MFA support (as described above) so that the SP can make the determination of whether MFA was successful and take the appropriate action in response.