issue with research.gov ?

[David Langenberg]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150818/49da3511/attachment.html>