make forceAuthn requests completely start over
Cantor, Scott
cantor.2 at osu.edu
Fri Jul 31 20:33:49 EDT 2015
On 7/31/15, 8:12 PM, "users on behalf of David Langenberg" <users-bounces at shibboleth.net on behalf of davel at uchicago.edu> wrote:
>Looks like I'm going to be learning more about SWF this weekend.
I've thought, not a lot maybe, but not insignificantly, about how to combine flows. Chad early on was planning to design around supporting "composite" flows for logins but that got dumped pretty early in favor of a simpler design, and I don't know if it's possible to get that back or not.
It's not terribly hard to call one flow from another, but the problem is all the context tree manipulations and assumptions built into the login flows because they were designed to be "self-contained" in producing a result.
That's what keeps bringing me back to doing a combined flow that just implements both pieces internally, and my plan was to build something general as an example that had a spot to plugin the second factor, whether it was Duo or whatever. I couldn't think of a better way to handle this.
I already designed for the case where a single flow could be implementing multiple methods because I use that at OSU, to fall through from password to SecurID in one flow (I don't have this in V3 yet, but it's easy to translate to that). What I fixed in this version over V2 was that a single flow can dynamically return different kinds of results and everything still works properly.
So a combined Duo + Password flow can easily decide to just do the password half if it wanted (or the Duo half for that matter), it's just a question of code. I envisioned that it would be able to examine the IdPSession (if it exists) and determine whether there was an active AuthenticationResult for the password portion and that would be a way of knowing whether to bypass that part or not.
Basically I can pretty concretely see how to implement this in code that isn't really all that deep, I just don't see how to generalize it away from that specific case so that two separate implementations could magically combine into the right answer in any given situation without a pretty significant redesign.
And there's the other possibility Marvin had mentioned, treating the SFA supplement as a post-authentication step that would just do all the fix up work at the end to add in the additional factor if it needed to. That isn't ideal, but once it's down to writing code, whatever's simpler probably wins. I still tend to think doing one login flow for both will be easier than that, but without having done either, I don't know yet.
-- Scott
More information about the users
mailing list