<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">Is it enough that you can already do a special attribute resolution step within the authentication flow?</blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>I looked at that, though admittedly not carefully. I ruled it out primarily because it fired before authentication.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or are you reacting to the requirement to do a password-based login up front to get that to work?<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Password authentication must succeed in order for the Duo flow to fire. Hope that answers the question.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess what I would ask is, what is that you really want it to do from a user PoV? What's supposed to happen in particular cases (session already exists, doesn't exist, etc.)?<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I want to prevent the user navigating away from the IdP prior to completion of 2-factor auth and subsequently accessing a service on the existing session. </div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Deferring the session update is probably not a big deal, but I'm also not sure what it buys you. Updating the session just records something that happened, and deferring recording it doesn't really prevent it from having happened</blockquote><div><br></div><div>I hope I can articulate that order matters. Modeled as an interceptor flow, the Duo login form renders _after_ session creation and setting of the browser cookie. That allows bypassing the Duo login, just by clicking away when the Duo login form renders, and subsequently accessing a service (same or another) on the existing IdP session.</div><div> </div></div></div><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 definitely feel like something is very wrong if you have to use an interceptor flow to support a login flow.</blockquote><div><br></div><div>Don't disagree, but the attribute resolution machinery seems to naturally come _after_ authentication. It would fit nicely as a login flow if I didn't have to query for user data to signal it; but we are assuming there will always be a need for opting out on a user basis, and we want to build that from the start.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd much rather add tools or pieces for login flows to take advantage of than ever have the IdP exit the authn flow without having actually completed auhentication.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Sounds good, but I don't see a good alternative at present. Open to suggestions.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div></div>