<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 4:45 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7/31/15, 6:03 PM, "users on behalf of David Langenberg" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:davel@uchicago.edu">davel@uchicago.edu</a>> wrote:<br>
<br>
>Is there a setting to make the v3 IdP completely start over when it receives a forceAuthn?  In our setup, we allow users to elect to force Duo for shib logins.  The way we accomplish this is to use Password flow for InitialAuthn and then provide the IdP with only Duo as the only allowed AuthnContext for that user.  We then setup the Duo AuthnContext to be equivalent to PasswordProtectedTransport and all is well.<br>
<br>
</span>I haven't reviewed any of these handlers yet, but I'm about 90% convinced it's a bad idea to do all this without doing the password step inside the same flow with a second factor. Anything else is going to have a lot of edge cases that lead to problems.<br></blockquote><div><br></div><div>Yeah, we don't want to do that as it would lead to a user having to enter their password twice to authenticate (once for the initial flow & once for the Duo flow).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>Unfortunately, in our testing we have turned up that a later forceAuthn request causes only the Duo flow to re-fire.  I understand why this is happening, but was wondering if there was some setting I could change that would instead cause a forceAuthn request to also fire the InitialAuthn flow and re-calculate from there?<br>
<br>
</span>The forceAuthn filtering step happens for both authentication phases, and all it does is prevent a result from being "reused" and limits the flows that can be used to the ones that claim to support that feature.<br>
<br>
I can't think of any reason it would only run the Duo flow in this case unless you had Duo enabled for initial authentication or the password flow was something custom and wasn't actually honoring forceAuthn.<br></blockquote><div><br></div><div>Ok, well, what from the logs would you want to see?   Sending a massive log barf at DEBUG/TRACE is probably not ideal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
By itself, the Password flow provided if it's the only thing enabled pretty much has to be run, because the ForceAuthn flag will prevent the old result(s) from being reused to exit the flow. SelectAuthenticationFlow is where that all lives and it has specific logic that checks for ForceAuthn, fairly simple code in that particular leg.<br></blockquote><div><br></div><div>Good to know it's supposed to not use any previous results.</div><div><br></div><div>Dave</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>David Langenberg<div>Identity & Access Management Architect</div><div>The University of Chicago</div></div></div></div>
</div></div>