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 is 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 theat 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:
When the IdP is authenticating in bypass mode, what should be sent to SPs indicating that the AuthN context is different?
There are really two circumstances here:
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 assert Duo/MFA success when authentication is done via "fail-open".
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., be easily reconfigured to allow for "Password Protected Transport" logins in the event of an MFA failure event).
2) The IdP enforces MFA based on local criteria (not based on specific requests from the SP) and does not communicate the fact of MFA
In this case the SP is presumably not invested in the success of the MFA, and the IdP can indicate authenticate 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. SPs that do not wish to support "fail-open" can be handled on an exception basis or, preferably, be reconfigured to explicitly request MFA support so that they can make the determination of whether MFA was successful themselves.
If the SP cares, then it should request the MFA (or equivalent) profile/service, but it needs to explicitly decide how it will respond in the even the IdP cannot do MFA. Almost along the lines of, should MFA-desiring SPs be required to also allow PPT responses (even if the user it told “you can’t access because you didn’t actually do MFA”)>