New 3.2 bean shibboleth.IgnoredContexts

[Cantor, Scott]

On 12/4/15, 10:15 AM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>So I noticed the new 3.2 bean called shibboleth.IgnoredContexts. 
>
>- Could that be used to force a 2FA method (e.g. Duo) even if an SP explicitly includes a request for PPT, by specifying PPT in that list?   (And specifying a defaultAuthenticationMethods of 2FA for the SP in relying-party, of course.)  

That isn't standards compliant (and neither is ignoring unspecified, strictly speaking, so I fixed the bug by just implementing an ignore list rather than hardcoding it). There's no provision in SAML for ignoring a requested context. Unspecified is a special case because it just doesn't make any sense (and it's a bug that it's in SAML in the first place, but I wasn't dealing with programmers who could understand why "null indicators" in specs don't work unless the field could never *be* null)

The reason for the feature was just to allow people to manipulate this if there's an interop problem they can't solve any other way.


>- Are there are any "negative impacts" of that, as long as PPT is otherwise the default method, and the Duo flow is configured to satisfy that also?

A Duo flow can only satisfy that if it guarantees that a password was collected. But yes, if you start messing with the spec, you're going to break stuff.

>- Would the requested authn context (e.g. PPT) still be returned in the Authn Response?

Almost certainly not.

>- Can ignoredContexts be done on a per-SP basis? (Activation condition?)

No.

-- Scott