Autumn flow: MFA and Password interoperability

[Mak, Steve]

We've created a custom checkSecondFactor script that defers the nextFlow to an external web service.  At this time we don't compare SP authContextClassRefs or do the isAcceptable() check and that was a deliberate decision.

For brevity I said our MFA uses Duo, but we built a custom flow in place of Duo.


From your response, is it your opinion that we should use MFA flow for all apps, properly bypass the second factor for specific apps, and let the MFA flow use the "properly built" merged results to determine if a two-factor step up is required?


On 7/9/19, 11:54 AM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

> Is it possible with out of the box config to have the MFA/Password flow context
> fulfill the Password flow for the relying party override?

It would. The principals in the MFA result will be a union of Password and Duo's configured set, and so it would work fine to satisfy an app that is configured to request or require just a PasswordProtectedContext principal/context class.

I think you probably handled the non-MFA case incorrectly in the configuration and aren't instructing the system what to do with the right level of abstraction. As long as its defaultAuthenticationMethods property is overridden to indicate that it only needs PasswordProtectedContext or whatever, it should work fine as an exception case and the isAcceptable() check that the shipped examples use as a control test in the MFA flow will work correctly.

-- Scott

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net