make forceAuthn requests completely start over

[Cantor, Scott]

On 7/31/15, 8:33 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>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.

Though as I'm perusing the code, it isn't that dire.

In the Password flow, pretty much everything that it does as a "final" step is in net.shibboleth.idp.authn.AbstractValidationAction.buildAuthenticationResult()

That isn't rocket science, and I don't think it's rocket science to invoke that as a subflow from within another login flow and still make sure the final state is appropriate.

It's important to note that, lack of documentation aside, the tree state expected at the end *is* formally part of the API and is not something that changes before 4.0 (if then). It's not all that extensive:

- populate AuthenticationContext.authenticationResult
- create/populate a SubjectCanonicalizationContext under the ProfileRequestContext

The question really becomes whether having the Duo flow run the Password flow in a black box way is appropriate for the usability result you want to get, since the UI of the Password flow obviously isn't meant to have anything else in it. But if we address the specific subject of this thread, the Duo flow could certainly achieve the result you wanted to get in the presence of ForceAuthn by invoking the Password flow itself.

Calling a subflow inside a flow definition is also trivial:

<subflow-state id="CallPasswordFlow" subflow="authn/Password">
	<input name="calledAsSubflow" value="true" />
	<transition on="proceed" to="next" />
</subflow-state>


Lot of options because there are lot of directions one could go.

-- Scott