Where to put multifactor flows
Marvin Addison
marvin.addison at gmail.com
Wed Jul 1 16:35:36 EDT 2015
>
> Is it enough that you can already do a special attribute resolution step
> within the authentication flow?
I looked at that, though admittedly not carefully. I ruled it out primarily
because it fired before authentication.
> Or are you reacting to the requirement to do a password-based login up
> front to get that to work?
>
Password authentication must succeed in order for the Duo flow to fire.
Hope that answers the question.
> I guess what I would ask is, what is that you really want it to do from a
> user PoV? What's supposed to happen in particular cases (session already
> exists, doesn't exist, etc.)?
>
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.
> Deferring the session update is probably not a big deal, but I'm also not
> sure what it buys you. Updating the session just records something that
> happened, and deferring recording it doesn't really prevent it from having
> happened
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.
> I definitely feel like something is very wrong if you have to use an
> interceptor flow to support a login flow.
Don't disagree, but the attribute resolution machinery seems to naturally
come _after_ authentication. 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'd much rather add tools or pieces for login flows to take advantage of
> than ever have the IdP exit the authn flow without having actually
> completed auhentication.
>
Sounds good, but I don't see a good alternative at present. Open to
suggestions.
M <dev-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150701/e3417b19/attachment.html>
More information about the dev
mailing list