Password quality pluggable interface scope
ghudson at MIT.EDU
Fri Aug 27 12:29:16 EDT 2010
On Fri, 2010-08-27 at 12:06 -0400, Marcus Watts wrote:
> I reworked the containing logic to apply even if there
> was no policy, and passed the policy *name* (or a null ptr if no policy)
> into the plugin in case the pw quality plugin wanted to do something
> different depending on the policy.
That's a decent compromise between keeping things simple and providing
some amount of policy configurability.
> I put a fair bit of effort into one other thing you don't list above:
> configuring the plugins, and providing 'system' parameters for the plugins.
> /2/ loading the same plugin more than once with different configuration.
> ... so I wasn't very interested in "zero configuration" rules.
Plugin modules can read profile associations; consider PKINIT
configuration variables, for example, or LDAP back-end configuration.
Is there a reason you prefer configuration of plugins to be modeled as
system parameters? What are the use cases for loading the same plugin
more than once with different configuration?
> As I said before, I think the built-in parameters for policy records
> is unduly restrictive. I'd like to see a much more extensible format here.
I would too, but I'm afraid this aspect will probably have to wait for a
more comprehensive KDB-related project. We've had other requests for
KDC-related plugins to be able to store extensible data within the KDB,
so that may be a 1.10 project.
More information about the krbdev