Where to put multifactor flows

[Cantor, Scott]

On 7/2/15, 1:33 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:

>Looking an an authn flow, my inclination is to simply build a one-off of the Password flow and add the following after the ValidateUsernamePassword action:

I think you could do all that by just using the initial-authn thing, but more generally I do agree that the path of least resistance is to build a new flow combining Password and Duo stuff. I really don't know how to build a generic layer that can really orchestrate all this crazy stuff. This is my ongoing problem with these SFA solutions.

>I'm familiar with that feature in name only. Can you point to a code reference where I can study for more information?

The code isn't separate, it's actually just the same thing wired in twice. When the profiles get to the login step, they do a step called CheckForInitialAuthentication, which you'll find in sso-abstract-flow.xml (and I realize now I never talked to you about it for CAS, which should be doing the same thing).

The profile flow conditionally runs the authentication subflow twice. The assumption is generally that the first time is running the Password flow unconditionally, though it doesn't really assume that.

Anyway, this all led to modifying the authentication flow so that if a session already exists when it runs, it does some extra steps, including optionally doing attribute resolution. The trigger was expected to be doing the initial authentication, because that gets a session created so that when the authn flow runs the second time, it will see that and trigger the attribute lookup.

The profile just does a little extra work to call the subflow twice, the authentication flow handles the rest.

This is all more theory for me than practice, but I thought about it primarily because it seems like you're trying to make the password part happen no matter what, and that mostly seems to do that for you, along with having it do the attribute lookup for you afterwards.

There's also, of course, what Daniel's been talking about on-list, using the authentication step to pull back attributes from LDAP if you're using the LDAP back-end.

>I think a general subflow dispatch feature modeled after the intercept flows could work well. Defining general requirements would be tough, but at a minimum an AttributeContext should be available to drive predicates/conditions for what subflows to invoke.

Because I already have a lot of signaling already implemented, what I was hoping to do was just reuse that by making the existing login flows more customizable in what event they signal back. If I can allow for that, then it should be straightforward to chain them.

The part I'm very fuzzy on is making all this work right in the presence of requests that are requiring MFA, since that should by rights skip the password step entirely. I kind of assumed that for that to work, a flow for something like Duo would really have to do some checking for whether the password part was done already and run it if it hadn't.

-- Scott