Bug in handling user certifications for specific contexts?

[Wessel, Keith]

Yes, and what you described, David, is what I had in mind. I like the idea of the same subflow being called for Password and for the principal gathering part of Duo, too; just one common piece of code to maintain in that case.

Keith


-----Original Message-----
From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of David Walker
Sent: Wednesday, September 09, 2015 1:49 PM
To: dev at shibboleth.net
Subject: Re: Bug in handling user certifications for specific contexts?

Right, and as you and I agreed, Scott, I'll get a bug properly filed. 
Keith's comment, while related, is not the same as the bug.  My earlier post of a few minutes ago is probably more related to Keith's comment.

David


On 09/09/2015 08:58 AM, Cantor, Scott wrote:
> On 9/9/15, 11:45 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>> On 9/9/15, 11:22 AM, "dev on behalf of Wessel, Keith" <dev-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>>
>>> I suggested yesterday on the call that I had with the two Davids that it'd be nice if there was some way the IDP could be configured to know that before running Duo (or some other 2nd factor method), it must run password explicitly.
> But also, I'm not saying there's not a bug. The FilterFlowsByAttribute action isn't like the FilterFlowsByForceAuthn action or some of the others that I copied it from, it isn't enough to just filter methods for selection, the system needs to be applying the same filtering to active results before it lets them get reused.
>
> I'm just saying like all complex changes, it probably will have some unexpected effects that limit SSO in cases that aren't self-evident until they come up. But it can only fail safe, so it can't hurt that much.
>
> -- Scott
>

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net