Comment 7 for bug 963098

Some OpenStack users will have specific, stringent, and organizationally-defined requirements for any controls that preform account lockout, while other organizations will be more concerned with a DoS of user access (things like this: http://capec.mitre.org/data/definitions/2.html).

From my view, there are a lot of different user account management requirements between organizations, and building features into keystone to support different requirements may not be tremendously valuable. A lot of authentication products support this type of functionality in a highly configurable way, and a lot of organizations have tools in place to facilitate these controls. By focusing on providing an interface between keystone and in-place authentication tools we allow the in-place processes and solutions to apply to OpenStack resources without requiring change.

With these thoughts in mind, I would posit that account lockout and re-enabling is an organization-wide authentication process / control and not necessarily an OpenStack-specific control, so I imagine in a lot of deployments this will be left to the back-end identity provider for many OpenStack users.

With all that said, it most certainly makes sense to me to build some functionality within keystone that implement basic account lockout for users who aren't backending keystone with another tool; but exploring a robust set of features in for account lockout may not be necessary.

One last thought: it strikes me that for any account lockout features built in to keystone we may want to consider automatically disabling any of these features when a backend authentication provider is configured to avoid troubleshooting confusion in the event of an account being disabled.