issue with research.gov ?

[IAM David Bantz]

I find one other SP that requests PPT and lo and behold my current
configuration does respond with the appropriate PPT AuthnContextClassRef -
even if I am configured to always require Duo 2FA.

I think (please correct me if wrong) that works because of this in
multi-context-broker.xml:

        <context
> name="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
> method="password">
>             <allowedContexts>
>                 <context name="...mfa
> <https://iam.alaska.edu/trac/wiki/mfa>" />
>             </allowedContexts>
>         </context>


David L rightly pointed to research.gov's additional requested context of
"unspecified" is what's breaking my config.

That doesn't tell me, though, why, when the SP requests "unspecified", the
IdP responds with either "Password" or "...mfa";
so I don't yet understand what sort of configuration change I need to avoid
that behavior.  WAG: could I explicitly indicate NO allowed contexts for
"unspecified" context - would the MCB then fall back to satisfying PPT as
it does if that's the only requested context?

db


On Tue, Aug 18, 2015 at 4:12 PM, David Langenberg <davel at uchicago.edu>
wrote:

>
>
> On Tue, Aug 18, 2015 at 7:05 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
>> On 8/18/15, 8:01 PM, "users on behalf of David Langenberg" <
>> users-bounces at shibboleth.net on behalf of davel at uchicago.edu> wrote:
>>
>>
>>
>> >I wish I could show you something cool & clever.  Unfortunately, I had
>> to in the end eliminate Password from anywhere in my configs (only using
>> PPT) and then gave my users a choice.  The distasteful choice was could use
>> research.gov <http://research.gov> or they could be defaulted to 2FA.
>> Those who were negatively affected chose to opt-out of electing to force
>> Duo.  Now, that said, things seem to work properly under IdPv3 (
>> research.gov <http://research.gov>
>> > seems to at least see me).  I'll see if I can track down somebody who
>> uses the site & get them to try Duo.
>>
>> IIRC, when you were working through issues earlier, you said that you had
>> associated Duo with the PPT context in the config.
>>
>
> Yes, I did do that, however, the MCB puts a precedence order to the
> AuthnContexts in the request.  The fact that Unspecified shows up before
> PPT in the list to the MCB means "prefer Unspecified".  This caused the
> logic flow to assert Duo or Password rather than the requested PPT.
> Eliminating Password from my config in favor of PPT combined with "Don't
> mix Duo with research.gov" was my eventual workaround.
>
>
>>
>> Also, in general, the only hard constraint is at the end. Whatever the
>> various flows are configured to handle, it's only the result at the end
>> that's cross-checked (but unlike V2, that check is basically impossibly to
>> circumvent, it won't respond with a context that doesn't match the request,
>> to prevent a spec violation.
>>
>
> Yep and in my quick tests, our V3 IdP (which is in production currently)
> seems to be doing the right thing.
>
> Dave
>
>
> --
> David Langenberg
> Identity & Access Management Architect
> The University of Chicago
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150818/9078dca7/attachment.html>