Where to put multifactor flows
Cantor, Scott
cantor.2 at osu.edu
Wed Jul 1 17:20:31 EDT 2015
On 7/1/15, 4:35 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>I want to prevent the user navigating away from the IdP prior to completion of 2-factor auth and subsequently accessing a service on the existing session.
Hmm. So the real problem is that it's recording a password result, and that's totally *meant* to be usable to access services that don't say they need anything better.
I guess I would say that this doesn't feel so much like the job of the Duo flow, but now it feels like an authorization flow (and much more sensible to do with an intercept), or possibly just forcing the allowable login methods for services.
>I hope I can articulate that order matters. Modeled as an interceptor flow, the Duo login form renders _after_ session creation and setting of the browser cookie. That allows bypassing the Duo login, just by clicking away when the Duo login form renders, and subsequently accessing a service (same or another) on the existing IdP session.
Only if the password result satisfies that service's request.
I feel like maybe it's not the Duo flow's job to enforce that though.
>Don't disagree, but the attribute resolution machinery seems to naturally come _after_ authentication.
It's running in multiple places now, but this doesn't feel like it has anything to do with attributes. Looking up attributes doesn't prevent the user from doing anything, and it doesn't impact how results are tracked...
> It would fit nicely as a login flow if I didn't have to query for user data to signal it; but we are assuming there will always be a need for opting out on a user basis, and we want to build that from the start.
I think the problem is not fundamentally about attributes. The problem is that you want to keep it from recording the Password result. I think.
I'm not understanding, I guess, when you *do* want it to record a Password result. If you never do, maybe you should just tell it to not persist that result...but that seems unlikely to be what you want.
Note...you could also have conditions attached to control the "do I persist the result?" question by checking attributes. Never thought of that, but it should work.
-- Scott
More information about the dev
mailing list