DUO Health Check Fail

[Steven Premeau]

Gary -

  What your IDP does in that case would be dependent on your MFA
configuration.

  Unfortunately, I don't have an example to show you on how to handle the
health check exception by skipping Duo, as we made the intentional decision
to fail securely in our implementation.  This prevents the risk of any
(appropriately resourced) malicious user from mounting a DoS attack and
bypassing Duo protections.  Bypassable MFA is not MFA.

  Also note, even if you are able to code up such a flow, your IDP will be
aware that MFA did not complete, and -- if correctly configured -- your IDP
will not be able to satisfy any login request requiring MFA (such as NIH).
 (And, if it does complete the authentication, it is likely misrepresenting
the authentication information to the service provider, which could present
liability or trust issues depending on the circumstances.)

Steve.

On Tue, Jul 30, 2024 at 11:00 PM Lipscomb, Gary via users <
users at shibboleth.net> wrote:

> Hi list,
>
> We had an incident on the weekend after a firewall update  caused access
> to DUO to be blocked and the Health checked failed.
> Subsequently any sites requiring MFA failed authentication.
> SSO password authentication was OK for non MFA protected sites.
>
>
> 22024-07-28 00:03:10,338 - 203.189.4.16 - ERROR
> [net.shibboleth.idp.plugin.authn.duo.impl.HealthCheckDuoOIDCAuthAPI:97] -
> Profile Action HealthCheckDuoOIDCAuthAPI: Duo API health check failed
> net.shibboleth.idp.plugin.authn.duo.DuoClientException: Could not execute
> Duo HTTP request
>         at
> net.shibboleth.idp.plugin.authn.duo.nimbus.impl.NimbusClient.executeRequest(NimbusClient.java:271)
> Caused by: java.net.SocketException: Connection reset
>         at
> java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
> 2024-07-28 00:03:10,339 - 203.189.4.16 - WARN
> [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event
> occurred while processing the request: AuthenticationException
>
>
>
> From reading from
>
> https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1374027959/DuoOIDCAuthnConfiguration#Advanced-Topics
>
>
>
> Before each Duo 2FA request, a back-channel lookup is made to Duo’s health
> check endpoint to determine if the Duo servers are accessible and accepting
> requests. If for some reason they aren’t, the 2FA attempt fails but the
> IdP’s authentication flows resume. This is a standard part of Duo’s 2FA
> workflow. The benefit of this approach is, it occurs before the URL
> redirect in the browser, and if the Duo 2FA endpoint were not available the
> IdP remains in control of the authentication process. Otherwise, the user’s
> browser might timeout during the 2FA request, or the user might get stuck
> on an error page of some kind.
> However, this involves an extra, frequent, back-channel network lookup and
> as such is subject to the same reliability/availability issues as the
> actual 2FA request. From investigation, it appears possible to bypass this
> check and still have the 2FA proceed as normal. Consequently, from v1.3.0
> onward we have included a property (*idp.duo.oidc.healthcheck.enabled*)
> that allows the deployer to turn off this check.
>
>
> Should the SSO have just continued , basically bypassing MFA?
>
> Is there a configuration we have missed for MFA?
>
>
> regards
>
> Gary
>
>
> *Gary Lipscomb*
>
> Technical Officer, Systems
>
> IT Infrastructure & Security | Division of Information Technology
>
>
> Charles Sturt University, Bathurst, NSW 2795
>
> Ph: 02 6338 6533
>
> Email: glipscomb at csu.edu.au
>
> csu.edu.au <http://www.csu.edu.au/>
>
>
>
>
>
-- 
Steven Premeau, Director of Enterprise Systems Architecture & Administration
University of Maine System: Information Technology
(207) 581-5836 (desk) | (207) 944-9391 (mobile)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240731/049cf287/attachment.htm>