<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but you could turn it on so that both runs through the authn flow behaved similarly, just with a different set of login flows.<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would need to figure out the error handling, I think it would need to change a bit since it shouldn't be an error necessarily to not find a flow to run, which normally would be a failure.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I hadn't filed an issue on it yet, you can if you think it's useful.<br></blockquote><div><br></div><div>I'm happy to file an issue and help test if I can get clear on mechanics.</div><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>