Where to put multifactor flows

[Cantor, Scott]

On 7/14/15, 10:56 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>That sounds like it would provide flexibility so that Password method of initial-authn is not assumed, which is what we need. I'm unclear what happens on the second pass through the authn subsystem; is there a flag that prevents duplicate processing by the actual auth mech?

SSO kicks in. The initial-authn run is trying to get a Session in place so that when the "real" flow runs, if it's already done what's required to satisfy the request it just falls into the SSO logic and reuses the result.

>You mean the case where a flow can't be found due to unsatisfied RequestedPrincipalContext? If that's what you mean, I don't see why it would matter. It would fail on the second round anyway and amount to the same result afaict.

Well, the assumption for the initial-authn case is that you're limiting the set of flows that might be available, otherwise there's not much point in doing it. If you limit the initial set and then apply RequestedPrincipalContext logic to which runs are usable, the assumption I'm making is that the "real" set is larger and so the second run might not fail.

That's an assumption, but it seems like a valid one. I'm sure there could be cases where it won't hold, but I don't understand what they would be. Running initial and "regular" authn with the same set of flows and both honoring the RPC rules would seem to be truly redundant.

The "initial" run seems like it should have to be different in some dimension, either in the flows that are active or in whether the RPC is looked at.

-- Scott