Where to put multifactor flows

[Cantor, Scott]

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


>
>It occurs to me that perhaps there's a reasonable feature that might be implemented to support this case, namely authn flows driven by user attributes, which I anticipate could be commonplace. Add a flag to defer the UpdateSessionWithAuthenticationResult
> action until after the interceptor flows complete. I haven't fully analyzed the consequences of that choice, but it seems straightforward to implement and I believe it would meet my needs.

Is it enough that you can already do a special attribute resolution step within the authentication flow? Or are you reacting to the requirement to do a password-based login up front to get that to work?

I confess that I'm not thrilled with that either, but that was how the MCB extension worked, so that's where the model came from.

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.)?

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, and usually it's the fact that it happened at all that impacts what the user sees (e.g. a password prompt).

I definitely feel like something is very wrong if you have to use an interceptor flow to support a login flow. I know people are building second-factor login flows, and have done so, so I'm still hoping that it isn't necessary.

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.

-- Scott