make forceAuthn requests completely start over

David Langenberg davel at uchicago.edu
Fri Jul 31 18:53:41 EDT 2015


On Fri, Jul 31, 2015 at 4:45 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/31/15, 6:03 PM, "users on behalf of David Langenberg" <
> users-bounces at shibboleth.net on behalf of davel at uchicago.edu> wrote:
>
> >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.
>
> 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.
>

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).


>
> >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?
>
> 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.
>
> 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.
>

Ok, well, what from the logs would you want to see?   Sending a massive log
barf at DEBUG/TRACE is probably not ideal.


>
> 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.
>

Good to know it's supposed to not use any previous results.

Dave

-- 
David Langenberg
Identity & Access Management Architect
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150731/cefecdfa/attachment-0001.html>


More information about the users mailing list