selectively inhibit previous session

[Cantor, Scott]

On 5/21/20, 5:32 PM, "Jim Fox" <fox at washington.edu> wrote:

> My problem is that I want a Password flow to run and be successful.  Can I detect in my mfa script which flow
> established the session?

The session is simply a carrier of flow results to preserve them, it doesn't get created by them. The only thing the session does is add the address check as a global constraint. After that it's all about the results individually.

If my goal was to make sure that outstanding Password results produced prior to an account being locked were invalidated, then that would be a reuse condition on the Password flow that checked for the locked or invalid state (and granted, maybe that's a complex thing to check but I have to assume there's some way or this question wouldn't make sense).

Of course, I don't know many people that do this, they just leave it at whatever the lifetime on the result is and live with it, but it can be done certainly. Obviously it adds overhead to all SSO behavior by adding extra checking it has to do  on every request.

If that's not what you mean, I'm not getting the problem yet or how it would work regardless of where the code lived.

Adding the condition to the Password flow is basically the same as attaching it to "the session". If it's false, the result is ignored for reuse, just like if the session as a whole had been ignored. But it's more fine grained since it can apply selectively to each factor in a more complex scenario with different conditions (or not, could be all the same condition).

-- Scott