IDP 3.3 MFA flow -- checking to see if an authn context class ref was requested

[Wessel, Keith]

Our specific case is based on:
(1) not everyone has Duo tokens yet, so I can't just make a simple MFA flow of always do password then Duo
(2) Some SPs will request Duo, others will request Duo or Password in that order, others won't request anything in which case password is sufficient for now.

In the case where either Duo or Password are requested, the isAcceptable method will work. But if both are requested by the SP, won't isAcceptable always return true once the user has satisfied password? If so, Duo will never happen.

Or perhaps I don't understand exactly what isAcceptable is doing?

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, December 05, 2016 2:15 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDP 3.3 MFA flow -- checking to see if an authn context class ref was requested

On 12/5/16, 2:54 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

> But I'm missing something based on your answer. What you say makes sense and seems like a much cleaner approach
> than what I had in mind. But how do I check to see if, specifically, the Duo method needs to be used if I'm not looking
> at specifically requested contexts?

You test if the result of the Password flow is acceptable to the AuthenticationContext. If it is, then strictly based on the SP's request, you're done. If you want to force Duo anyway, that's more complicated because you're really going beyond what the SP requested, but you could do that by separately testing whether the Duo custom principal itself is acceptable. Not whether it's in the requested set, but whether it's acceptable. The difference is that the latter is true in all the possible cases where the IdP thinks it's acceptable.

For example, an SP that requests for "better" than Password doesn't include Duo in its request, but it's still exactly the sort of case that you'd want it to run. I'm not saying this is interoperable, I'm just saying there's no reason to code it in a limited way when coding it the other way works in more cases.

> I don't want to prompt the user for Duo if the SP didn't ask for the 2nd factor to be performed.

If you really want to force Duo, then you might want to do that regardless of what the SP asked for, barring an SP requesting certificates or something like that. What specific case are you trying to *not* run the Duo flow? If an SP requests Password alone, that doesn't mean you couldn't still do Duo, since that still requires the Password requirement be satisified anyway. Do you gain much beyond a more complex set of rules by handling that case differently?

-- Scott


-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net