make forceAuthn requests completely start over

Cantor, Scott cantor.2 at osu.edu
Fri Jul 31 18:54:17 EDT 2015


On 7/31/15, 6:45 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
>
>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.

And this is why...

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

Except of course the initial-authn flow bails out if there's already a session, so of course that's why it's not running.

You can understand why ForceAuthn doesn't mean "dispose of session" in the general case since that prevents other SPs from leveraging SSO.

The purpose of the initial-authn flow that was explained to me and that I implemented was NOT to guarantee that it ran, but to guarantee that the user was identified. Not the same thing. I always assumed that if people really believed that SFA + SFA could be implemented in two flows, they would still absolutely have to be deployed during the main authentication phase. And if that didn't work (and I'm not at all sure it does), then that model doesn't work, and we need one flow for both factors. Which I'm pretty sure is what's required.

-- Scott



More information about the users mailing list