Bug in handling user certifications for specific contexts?

[Cantor, Scott]

On 9/10/15, 4:08 PM, "dev on behalf of David Walker" <dev-bounces at shibboleth.net on behalf of dwalker at internet2.edu> wrote:
>
>Dave Langenberg found that this works for "exact" matching, too.  I should have added the following to my earlier configuration snippet:

That's an example of using the IdP's extensibility to fool it into doing something fundamentally wrong. You can make the code behave in an incorrect fashion by doing that, and that is in fact incorrect SAML behavior.

>My presumption has been that the IdP would assert Password when using these rules, though, even if the Duo flow had been invoked, which raises some interesting issues:
>
>* What is the IdP's behavior in this case?  I'm guessing it would be necessary to configure the Duo flow to "support" Password.

I'm not saying it's "wrong" to do that. If you want that flow to assert Password contexts back, I think that's ok, because it should be possible for it to ensure that if it does so, it actually knows that a password login happened or is happening now. But it's not allowed to assert Duo back if an SP requests Password. That violates the standard and would be a bug. The IdP won't do that unless it's manipulated very deliberately to do so in a way we don't document or suggest.

>* Even more interesting (and, perhaps, for a different list)... I think many of us have been thinking that it's OK for an IdP to satisfy a request for a password context with something stronger.

It can do whatever it likes from a deployment perspective, but SAML does not allow it to assert any context back but the one that was asked for.

>Some contexts, like InCommon Silver and Bronze, define which is stronger, but others, like PasswordProtectedTransport or SmartcardPKI, do not.  Ultimately, this determination is made by the IdP, but do we need some community guidance/standards?  Should IdPs be encouraged not to use the PasswordProtectedTransport context, unless they explicitly mean that and only that?

I think you mean SPs, not IdPs, and the answer is usually that it's a bad idea. The only imagined use case I have ever seen for requesting Password or PPT as an SP is if the use of something stronger would cost the SP money. An example: maybe the IdP bills the SP back for any SMS or callback charges.

>Do we need a "Password or better" context as a companion to the MFA context that's being discussed in the current MFA Interoperability Profile Working Group?

If you preclude the use of inexact matching (which I'm not arguing is wrong, nothing but Shibboleth likely supports that), you can't really handle a lot of use cases properly without building the logic into the context class' definition.

>Yes, I left it out for simplicity, but it's there.  Here's a not-so-simple version:

I'll have to spend some time reviewing that, thanks.

-- Scott