Bug in handling user certifications for specific contexts?

[Cantor, Scott]

On 9/8/15, 6:16 PM, "dev on behalf of David Walker" <dev-bounces at shibboleth.net on behalf of dwalker at internet2.edu> wrote:



>When an SP requests Password, the user should be prompted for Duo authentication after the initial Password authentication.  Unfortunately, the IdP returns successful authentication after the initial Password authentication is complete, without the Duo interaction.
> Sounds like a bug to us; are we missing something?

The filtering by attribute is only applied to flows eligible for selection to perform a login, and not to active results. It was implemented alongside a bunch of filtering steps that are focused on filtering login methods to run, so it doesn't pay any attention to whatever's already been done before.

Preventing SSO reuse of a result is probably something I could add, but I'm not sure that the end result will be a working solution.

I don't think the right thing to do is to "hide" the password result because I suspect some second factor flows will want the ability to look at the session and figure out whether a password login was done already. I would probably need to add a constraint to the "master" Select action that blocks the reuse there.

I think there will be unintended consequences to virtually every change from here on out. But in isolation, if the user attribute contains "Duo" and the Password flow only supports "Password", then it would block SSO based on that result, and then run the Duo flow as the only option left.

-- Scott