MCB with Duo and password as fallback

[Wessel, Keith]

Where my situation gets tricky is that Duo can't be an initial authentication context. The Duo submodule uses a principal from another submodule. In my case, the only context that can be triggered initially, regardless of what was requested, is password.

If both Duo and Password could be initial contexts, it'd work as Paul describes.

But in filling the initial context, I satisfy password, and the MCB says "good enough."

So far, it's just unfortunate, but I can live with that.

Where I think something's wrong is when I go to my simple SP that specifies no authn contexts before going to the one that has duo then password configured. If the MCB is truly honoring the order of the string, it should prompt me to use Duo. It has the principal, I'm eligible for Duo. But it simply uses my previous session. I've satisfied password, so we use password.

I thought I tested this during acceptance testing and saw behavior like what Paul described. I can't get it to work that way now, though.

I'll keep digging.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, August 20, 2014 9:01 PM
To: Shib Users
Subject: Re: MCB with Duo and password as fallback

On 8/20/14, 9:45 PM, "Paul Hethmon" <paul.hethmon at clareitysecurity.com>
wrote:
>
>It does honor the order given by the SP.

Not based on what Keith is saying. Unless he's missing an option...

>So how the MCB would handle this would be up to the configuration.
>Assuming the two contexts are handled by different methods then X will 
>be presented first as requested. However, if the second SP request were 
>for method Y and Y is not satisfied by X, then the MCB would require 
>the user to satisfy Y instead of using previous session.

Keith is saying that it's not presenting X, because Y's already been used and it satisfies the SP as the context requested in second position.
That's what I'm terming "favoring SSO".

>If X and Y used the same method, then the second SP request would be 
>granted as a previous session no matter which context was requested, 
>since the user has already satisfied the method that covers both contexts.

Yes. We're actually talking about a simpler case where X and Y are not supported by the same underlying method so they're at least disjoint.

Things get much more complex when you change that, but I did handle that in V3 because not only do flows (methods) advertise the contexts they support, but *results* also do. So you might have a single flow handling X and Y, but when you do it once, you only got Y. So an SP that requests X won't get SSO, the IdP knows to re-run the single method because the result before wasn't good enough.

>I don't feel I'm adequately explaining what it can do here.

It's very difficult to explain any of this, which is why it has little chance of wide adoption. That's an aside, but it's something the higher ups need to get clear. You can't deploy what you can't understand. I can barely understand what the new version can do and I wrote it.

-- Scott

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