Credit for the idea to create this approach goes The project would like to extend appreciation to Steven Premeau, University of Maine System, for suggesting this feature, providing an initial contribution, and working extensively with the project to test and refine it.
| Note |
|---|
This feature requires V2.1.0+ of the DuoOIDC plugin. It is currently unreleased and this material is experimental in nature. In particular, the configuration is in flux, and the exact requirements needed to configure Duo will depend on some features that are currently only in preview. |
| Table of Contents |
|---|
Background
...
The new feature also has been designed with some knowledge of shared machine considerations, and also allows for various kinds of “gradual adoption” scenarios such as pilot groups and so forth, to manage the introduction of the feature to a large community.
Overview
Ultimately the MFA flow is used to control the use of this new feature and orchestrate the use of the flow in its new form or its traditional mode. Examples of how to configure this are included near the end of this topic, and of course the MFA flow feature in the IdP can be configured to do many more exotic things in support of this workflow depending on local requirements.
...
After a standard Duo authentication is completed, a condition is run evaulated against the request and if true, the subject is given a choice to “opt-in” so that an encrypted cookie containing the username is issued set for future requests. The plugin will also identify scenarios where an existing cookie should be removed. If the subject opts-out, then this decision is also remembered with a fixed cookie value to avoid constant nagging.
Subsequent requests with the feature triggered will detect the presence of the cookie, and it will (generally) present a new view prior to the handoff to Duo that identifies who it believes the subject to be so the person may indicate how they want to proceed.
If traditional login is preferred, or the subject self-identifies as a different identity, then control returns to the MFA flow with specific events, after which the MFA flow is expected to do what it had been doing originally, whatever that was.
If passwordless login is chosen, the plugin will invoke the Duo service using the desired passwordless integration.
The factor used is checked against a set that is deemed acceptable (configurable of course) and if so, the resulting Java Subject will automatically include a UsernamePrincipal object containing the username passed to Duo, allowing the MFA flow to potentially complete with no additional configuration needed.
...
Title | Description | File |
|---|---|---|
Standard Username and Password Authentication | The user has not opted into passwordless authentication, and the service provider only requires password authentication. This demonstrates a standard, basic, username and password flow. | |
Opt-In To Passwordless Authentication | The service provider requires multi-factor authentication, the user performs multi-factor with Duo and uses a second factor that is acceptable for passwordless. The user opts-in to passwordless and uses that as the sole factor on the next authentication. | not-opted-in-requires-mfa-uses-correct-factor-and-opts-in.mov |
Unable To Opt-In to Passwordless Authentication | The service provider requires multi-factor authentication, the user performs multi-factor with Duo but uses a second factor that is unacceptable for passwordless. The user can not use passwordless for subsequent authentications. | opted-in-requires-mfa-not-eligble-for-passwordless-wrong-factor.mov |
Opt-In To Passwordless, But Then Use an Unacceptable Factor For Passwordless | The service provider requires multi-factor authentication, the user performs multi-factor with Duo and uses a second factor that is acceptable for passwordless. Opts-in to passwordless. However, for the subsequent passwordless authentication they change to an unacceptable sole factor. The login fails. | |
Already Opted-In To Passwordless, But Chooses The Password Flow | The user has previously opted-in to passwordless authentication but decides to use username and password authentication instead. | |
A Different User Using the Same Browser As A User Who Opted-In | A different user, using the same browser, opted-in to passwordless authentication. The current user recognises it is not them (and their credentials would not work) and uses the ‘Not You’ link. | |
Administrative Flow for User Control Of Opt-In Status | The user signs into the administrative endpoint to manage their passwordless opt-in status (cookie) | |
Administrative Flow for Admin User Control Of Opt-In Status and Username | A user, with administrative rights, signs into the administrative endpoint to manage both their passwordless opt-in status (cookie) and the username stored inside the cookie. |
...