Ok, I'm going to close this out as complete.

We can open more issues if something comes up. Interested to see what the final result looks like. Might be able to clean up some things at that point if I have a working example to look at.

Thanks a lot for having implemented all of this.

In the meantime, I could successfully test this with the SPNEGO login flow.
It works fine.

Calling the SPNEGO flow as a subflow from the Password login flow works fine.
The login can provide a checkbox for enabling autologin for SPNEGO, and the value is passed to the SPNEGO login flow via the AuthenticationFlowState map.
The flow can detect if called as extended flow and behave accordingly.

I think that this should fulfill all of our UI requirements for the SPNEGO login flow.

r7792, ExternalAuthentication class has a new request parameter containing true if called as an extended flow.

r7790

A state passing hook is now implemented. The shibboleth.authn.Password.ExtendedFlowParameters bean identifies any form parameters you want to save off. They're stored in AuthenticationContext.getAuthenticationFlowState() in a map of String or List<String> objects.

I also added a flow input parameter "calledAsExtendedFlow" set to true when it calls the flows, and mapped it into a flowScope variable. I'll add a hook to the ExtendedAuthentication class to pick it up and expose it to the servlets.

Personally I think it's eaiest to just create a cookie with Javascript. The only way we could pass anything across is with some kind of generic parameter known to the Password flow. I can probably define a flow input parameter into the subflow call that picks up the value of a generic parameter name. It can't be extensible to other parameters, not without editing the flow definition. And I would have to add something to the External flow API to carry it across, but that's doable.

The problem with allowing un-enabled flows to be injected is that it means I totally ignore the settings in other places that may have been intentionally used to control which login flows can be used with an SP. I don't think that's right or consistent. I'm aware that it means you have to install the Password flow above any of the extended flows that won't pass back control, but I don't see why that's a problem (I just have to document it). This isn't meant to override the rules controlling the flows that are enabled, it's an internal detail of the Password flow.

I can define a flow input parameter to use as a signal for how it's being called and if you want to complicate the other flow to use it, that's an option. I think it's overly complex though (you'll have to ensure any errors are routed back to the IdP as a ReselectFlow event), you could just run the Password flow and use Javascript to pick up the cookie and invoke the button.

Good catch on the error handling, will fix.