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