MFA enhancements in 3.3

[Cantor, Scott]

Just so I'm not working in a vaccuum, I've started work in earnest on the planned MFA enhancements for 3.3. which I'm tracking in IDP-962.

The approach is still mostly in my head, but will start turning into an actual flow design over the next week or so. One of the considerations was whether to try and address this by replacing or at least allowing for alternative behavior where the current authentication flow does the big selection routine to decide which method to try and use and generally has a "try each one until it works" semantic.

I decided for now not to try and just replace that, partly because it's a lot of work, it's a big change to code that actually works for a lot of use cases already, and it disrupts a pretty fundamental design assumption that every authentication act would produce a single result to track.

And, I think I can avoid dealing with that with the usual layer of indirection by building a flow to wrap a result that will contain results produced by other flows, most of the machinery for which I finished already.

My basic design:

- Continue to use and maintain fidelity with the custom Principal machinery that handles AuthnContext-driven criteria now.

- Make each factor implementable as a standard, self-contained login flow that conforms to the current system contract for login flows [1]. Password would essentially be usable as is. Additional factors (OATH, U2F, Duo, etc.) would not need to worry about getting the first factor to run like they do now and would be very simple to implement and plug in.

- Build a relatively simple login flow for MFA that does the job of executing other flows to produce results from the desired factors, but doesn't do any of the actual work itself.

- Allow it to reuse results produced by the consituent factors in the same way the master flow reuses results, so individual factors can be bypassed the same way authentication as a whole gets bypassed today.

- Drive the MFA flow with a simple configuration that maps each transition from one flow to the next with plug points that are overrideable to determine when authentication is "done", how to combine the different results into one final result, and if it's not done, what flow to run next.

It will be possible to embed calls to arbitrary webflows within the MFA flow, allowing steps like attribute resolution to be injected into the sequence wherever it needs to run.

My thought is that the current complex attribute-driven use cases for assurance should be possible to implement by executing whatever factor(s) are needed first, having it branch to a flow to do the lookup, and then executing a transition function that checks the resulting attribute(s) and decides what to run next. That's much cleaner than the filtering approach I tried to use up until now.

In addition, the default behavior will pretty much "just work" for the most common use cases like Password + <something> by allowing it to recognize when Password is acceptable for the request, and only run the second factor if it's not acceptable. So the normal step-up use case should be pretty trivial to configure, probably just naming the two methods to combine.

All of the functions and conditions the code will use to decide what to do are injectable, and can be written with scripts of course, like everywhere else in the IdP. So I think most use cases should at worst just involve writing some scripts, not code or new webflows.

I like this design more than trying to reimplement PAM and embed real semantics (sufficient, required, etc.) between the factors, because it's both more work to configure for common cases, and less flexible than just allowing scripts to be plugged in to decide on transitions.

-- Scott