Rehydrate context after expiringPassword intercept

[Cantor, Scott]

On 6/30/21, 12:21 PM, "users on behalf of Herron, Joel D" <users-bounces at shibboleth.net on behalf of herronj at uww.edu> wrote:

>    Fantastic... So I shouldn't be see the ExpiringPassword Interceptor run before the MFA flow runs.

There's an "old" way of trying to hook password "events" that was very ugly and I deeply regret, but it is there. It's not the same kind of thing though, and it runs before Password completes. So...no, you shouldn't, but there is a non-intercepty thing that exists and I wasn't sure if that was involved or not.

In terms of the intercept/expiring-password flow or the rest of them, no, it's not something we support, those are special flows that have be set up properly, which the system does internally and there's a very explicit pre/post contract involved that's documented to some extent in the Design side of the doc space.

> It should go after that fully completes in a normal setup?

Yes, interceptors can be inbound, outbound, or post-authn. Those are the three "exits" inside the full flows that know how to run configured interceptors based on the configuration of the profiles. That's what you're doing when you add "attribute-release" or whatever into the relying-party file.

> So somewhere my predecessor has set it up to run right after LDAP auth happens...

If it's being done by hand within the MFA flow by transitioning to intercept/expiring-password, no, that wouldn't be intended to work. It probably does, but accidentally.

I don't know why it would have any affect on Duo but that's not something I'd really be able to go digging into.

We have one here and it's just run after authentication normally, it doesn't seem to be awkward to do that. It's just something you see occasionally after you're done logging in, Duo or not.

-- Scott