selectively inhibit previous session

Cantor, Scott cantor.2 at osu.edu
Fri May 22 18:49:29 UTC 2020


On 5/22/20, 2:36 PM, "users on behalf of Jim Fox" <users-bounces at shibboleth.net on behalf of fox at washington.edu> wrote:

> My new plan:  I can detect in my mfa script 1) if a user is in the 
> compromised condition (method local to my situation) and 2) if the 
> Password result used a previous session.  From there I can invalidate the 
> session and basically let the user start over.

You're doing the same work, just in a less elegant way that's less clear from the configuration since it's not in a spot with a clear purpose/intent. The reuse condition isn't going to run any more often than that logic would.

Just follow the model as it's laid out and you will find that it's the same overhead.

The hard part is detecting the compromised case. If you can really do that efficiently, then the place to do it is the reuse condition, which has the advantage that you can assume going in that the Password result *is* from a previous run. There's no need to do that work.

> I think I could destroy the session with a subflow that just deletes the session 
> cookie, but that that seems kinda crude.  Is there a better way for me to invalidate 
> the session and then run the user through Password again?

I would strongly advise against that approach, and the code to do all that would be much more complex and harder to make reliable.

-- Scott




More information about the users mailing list