You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The following page offers advice for planning and handling outages to the Duo Security service.

Monitoring Duo

Duo offers a specific status page, https://status.duo.com/ with outage information, and is a good place to start.

Bypassing Duo

A few solutions were offered to support a fail-open integration, to allow AuthN to continue in a weakened state:

  1. Configure IdP to check group membership before prompting for Duo, and remove users from the group to bypass.
    1. Nebraska uses a CAS Duo Extension configured to check for a specific attribute value memberOf: cn=psp:orgs:idm:DuoEnabled,ou=grouper,ou=group,dc=unl,dc=edu
  2. ...

Communicating Change in AuthN Context to SPs

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.

  • No labels