The use of auxiliary object classes to encapsulate password validation parameters seemed like a good idea at the time. However, in practice it leads to a rather complex administration model. Here's a couple of examples:
- why should I add the ds-pwp-length-based-validator objectClass in order to specify a minimum length using ds-pwp-min-password-length?
- what does it mean to add the ds-pwp-length-based-validator objectClass, but not ds-pwp-min-password-length or ds-pwp-max-password-length?
In addition, the use of mix-in types like these is not currently supported in Rest2Ldap, and it would be difficult to add support because objectClasses are treated as immutable type information.
This issue can be closed once we have investigated whether it is possible to simplify the administration model by removing the auxiliary objectClasses. If it is possible, then the objectClasses should be removed.
After further investigation we found that some validators would still need some kind of on/off switch. The only alternatives to using an object class are to use an enum based attribute, which makes extension harder, or use a boolean attribute for each validator which is also not very extensible as well as being pretty ugly. We've decided that the best approach would be to add auxiliary object class to rest2ldap. Being a generic feature, it would be possible to leverage the capability for other use-cases as well.