<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">I meant that you should avoid trying to enforce anything in the Duo flow, and just build a separate flow to enforce whatever it is you're meaning to enforce afterwards. Two flows, one login flow, the other the authz flow.<br></blockquote><div><br></div><div>I see. That distinction wasn't clear to me initially.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, I'm *not* saying that I think it's trivial/obvious how to build a Duo flow and then glue that to the password flow appropriately.</blockquote><div><br></div><div>Looking an an authn flow, my inclination is to simply build a one-off of the Password flow and add the following after the ValidateUsernamePassword action:</div><div><br></div><div>- SetupTempSubjectContext</div><div>- ResolveAttributes</div><div>- RemoveTempSubjectContext</div><div><br></div><div>Then I have an AttributeContext I can use to optionally execute subsequent Duo-specific states. The SubjectContext setup is little wonky, but in our case the username is the subject we want to use, so I can capture the posted username in a flowScope parameter and trust that it's been authenticated since subsequent actions fire IFF the password is valid.</div><div><br></div><div>My main concern with a custom authentication flow isn't initial development, it's maintenance over time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One way of course is to use that initial-authn feature, set to Password, since that gets that part done for you and leaves you free to do the Duo part during the main authn step.</blockquote><div><br></div><div>I'm familiar with that feature in name only. Can you point to a code reference where I can study for more information?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But I'd like to have other options there. We can signal flows now, but I can't think of any obvious way to do the Password flow and somehow route from that to the Duo flow. That's the problem I'd rather focus on.<br></blockquote><div><br></div><div>I think a general subflow dispatch feature modeled after the intercept flows could work well. Defining general requirements would be tough, but at a minimum an AttributeContext should be available to drive predicates/conditions for what subflows to invoke.</div><div><br></div><div>M</div><div><br></div></div></div>