Password lockout approach

[Cantor, Scott]

> I'm looking to see if there are any suggestions as to where to
> plug this in.  I'd also like to do this in a relatively generic manner
> so others could make use of it.

I really don't know enough about the use case. There's an issue open on it, and I haven't spent any time considering what would be involved.

> It seems to me that the lockout concept would apply specifically to
> username/password authentication, and not other methods like X.509, but
> that it would not depend on the specific password backend (LDAP,
> Kerberos, etc.).  I'd consider the lockout "key" to be configurable, so
> I could use a stringified "username+IP", and someone else could use just
> username or IP by itself.

Probably all true. Anything that's pluggable like that now relies on Guava's Functions. We parametrize all our components by injectable Function objects that do the work of computing values like that.

> I'm wondering if most/all of these could/should be implemented in
> flows/authn/conditions/conditions-flow.xml#ValidateUsernamePassword,
> as it appears to be the "parent" state of the ValidateUsernamePassword
> state in the actual password-flow.

I don't know if it's possible. It can respond to events pretty much with total control, but "proceed" may be the exception. The proceed transition is declared in the child flow, and I don't think you can override that up in this "parent". I think I noted that while I was looking at a different use case.

There are certainly ways to fix all that, but not without changing system files or the Java code to add more flexibility.

> The other question would be where the attack counter/timestamps should
> be stored.  They need to persist beyond the individual flows, so flow
> scope variables seem to be out.  The various storage service APIs seem
> like they fit pretty well, but would we need to configure an separate
> storage service instance for this? Particularly if the default is to use
> cookies in the browser....

That's the default client side storage. The default server side storage service is in memory.

All storage clients have a property associated with them to specify the StorageService bean ID to use, and things can share one instance or be configured with different ones based on the use case.

-- Scott