Where to put multifactor flows

[Schwoerer, Brad]

I was looking at a similar thing for doing MFA with Symantec VIP.   An attribute on the person would flag them as either needing MFA for all unspecified/password flows, or the attribute could also be a list of entityIDs.   I couldn't come up with any issues with looking up the need pre-authentication and then taking action after ldap succeeded, but would very much like feedback as well of why that may not be a good idea.

Symantec VIP also offers a risk based authentication, where the return from that risk based check could also step them up to MFA.


-Bradley



From: Marvin Addison <marvin.addison at gmail.com<mailto:marvin.addison at gmail.com>>
Reply-To: Shib Dev <dev at shibboleth.net<mailto:dev at shibboleth.net>>
Date: Wednesday, July 1, 2015 at 3:35 PM
To: Shib Dev <dev at shibboleth.net<mailto:dev at shibboleth.net>>
Subject: Re: Where to put multifactor flows

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<mailto:dev-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150701/a9aecd19/attachment-0001.html>