MCB with Duo and password as fallback

[Cantor, Scott]

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