Event transition issue for IdP 3.3.1

[Cantor, Scott]

> I believe I see where we are causing this with our implementation of the
> flows/auth/conditions/expiring-password condition flow.  When triggered,
> we are giving the user the option to "change password now" before
> continuing the authentication.  The expiring-password-flow presents a form
> view to change the password, then inserts the new password into the UPC in
> the authnContext and then transitions back to
> "ValidateUsernamePassword", I guess to restart the authn flow, so to speak.
> Then due to a bug in 3.3.0, the expiring-password flow is having to do a
> manual c14n.  Maybe I can remove that step now.

Hmm. You're right that it doesn't fit the bug I caused, though that is still a bug. The problem with the conditions flow is that you can't safely use it like this. You can't make assumptions about the internals of the flow, all you can do is respond to events and then either continue or fail processing. Anything else is going to step into unsupported territory because we have to be able to make changes to the flow, which in fact I had to do and that broke even the feature we provided. It was a mistake to try to do it this way, but it's one of the earliest hook points I tried to create.

If I did it again, I would do it as a true subflow like the interceptors are.

> Our goal is to allow a user whose password is expiring soon the option to
> change the password, and then complete the intended authentication
> without having to re-enter credentials.

I think you should simply do it afterwards and not try and re-validate the credentials like that. If they already logged in and it worked, and it's not an expired password, have them change it, but why re-validate it?

But regardless, I don't know what it's not working, you would have to compare things. ValidateUsernamePassword is still a valid state. Perhaps you're just not transitioning to it correctly.

-- Scott