Complicating my MFA implementation

[Wessel, Keith]

Well, Duh, that was simple. Sorry, Dave and Mike, not sure how I missed that.

And yes, Scott,a good point to keep in mind.

Thanks to all,
Keith


-----Original Message-----
From: Cantor, Scott [mailto:cantor.2 at osu.edu] 
Sent: Tuesday, April 26, 2016 10:57 AM
To: Shib Users <users at shibboleth.net>; Wessel, Keith <kwessel at illinois.edu>
Subject: RE: Complicating my MFA implementation

> Case #1 (opt-in for everything) happens by removing the
> PasswordProtectedTransport from the eduPersonAssurance attribute for
> the user.  Since PPT is not allowed to be used, the IdP will look at the
> authNContextComparison stuff and see that Duo == PPT.  Therefore it will
> move on and make the user do Duo (since the user is allowed to use Duo via
> ePAssurance).

Pedantically, you don't want (or need) to tell the IdP that Duo == PPT. A given method can *support* PPT and Duo, and that's all you need to tell it. That is allowable if that flow ensures that in fact PPT happens, and that's more or less true with second-factor methods that rely on passwords for the first factor.

The difference is important, because you will break the IdP (meaning it will be able to violate the rules) if you actually convince it to treat those two values as "equal" in a real sense. Do not do that.

-- Scott