Change password flow ?

[Cantor, Scott]

> + conditional business logic
> + lockout ? (e.g. too many attempts)
> + log/audit intent to change password

I know people have barked a lot about the audit log not being architected around authentication events but profile events. Might be time to look at adding a layer for having multiple audit streams handling different sorts of events, can be based on the same code I did but just tracks a different set of events and records things at different point in the flows.

> Not familiar enough with JAAS to understand what you mean regarding the
> series of beans, but it makes me think of multiple "change password" steps
> from the above sketch.

It's stackable modules that run in sequence or stop when one succeeds or whatever, PAM-like. My guess is some people will want to propagate the reset to multiple stores, and that if the counter to that is "you should have all that handled by your IDM system" I would argue that means the IdP shouldn't need to do any of this to begin with.

-- Scott