ECP on an idp configured for MFA

[Cantor, Scott]

(The intended punch line here is that in the majority of cases, you're still "just" enabling the MFA flow like before, ECP doesn't change that.)

-- Scott

On 2/19/19, 4:59 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

On 2/19/19, 4:49 PM, "users on behalf of Paul B. Henson" <users-bounces at shibboleth.net on behalf of henson at cpp.edu> wrote:

> What is the recommended configuration for an idp that is using MFA to also support ECP?

Make your MFA logic and all the subordinate flows do whatever's necessary to support your use case, basically. There's no recommendation, it depends on whatever it is you expect to happen and whether it's technically possible.

Executing other flows from the dispatching rules will honor the nonBrowserSupported flag on the login flow descriptors so if it dispatches to something that doesn't allow ECP use then it fails to run that method. You have to make sure that failure is the expected outcome in such a case if it's possible for it to happen.

The Password flow supports ECP so an MFA rule running it will work. Duo can support it, but only if it's configured to, so the flag is off by default and has to be turned on to signal that it's usable. Other flows might or might not support ECP.

If an app requests/requires some kind of method that can't be satisfied, then the result will be the same as in any other case like that outside of ECP, it fails with a status code for that case.

Basically it just all works except when it doesn't. All of that is ultimately governed by the nonBrowserSupported flag on the methods your logic tries to run. You also of course have the ability to test for the situation at runtime and behave differently in the MFA flow based on that, so it's possible to define different login flows and use them in specific cases.

-- Scott