[OPENDJ-6879] Rest2Ldap should support auxiliary "mix-in" object classes in order to support enhanced password policies Created: 19/Dec/19  Updated: 28/Jul/20

Status: Dev backlog
Project: OpenDJ
Component/s: rest, security
Affects Version/s: 7.0.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Matthew Swift Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Depends
is required by OPENDJ-6993 Update doc for OPENDJ-6879 QA Backlog
is required by OPENDJ-7086 Revisit doc on creating a subentry pa... Dev backlog
Story Points: 10
Dev Assignee: Matthew Swift

 Description   

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.



 Comments   
Comment by Matthew Swift [ 20/Jan/20 ]

After discussing with Chris Ridd we decided that it would be better if rest2ldap supported auxiliary object classes.

Comment by Matthew Swift [ 19/Feb/20 ]

There's a slight difference between LDAP schema definitions and Rest2Ldap mappings that makes auxiliary object class support a little bit ugly: LDAP object classes definitions are aggregates of attribute type definitions, whereas Rest2Ldap resource definitions are compositions of property mappings.

The implication is that if two auxiliary object classes share the same attribute type(s) then the associated Rest2Ldap mapping will need to duplicate the same property mapping.

Comment by Matthew Swift [ 19/Feb/20 ]

It should be possible to add and remove auxiliary object classes using update and patch operations.

Comment by Matthew Swift [ 21/Feb/20 ]

Rest2Ldap JSON resources effectively expose their structural objectClass via the mapped _schema JSON property. For example, frapi:opendj:rest2ldap:user:1.0 is mapped to LDAP inetOrgPerson. This JSON property is single valued, therefore we cannot use it to convey any additional auxiliary type information.

I propose extending the JSON schema to have an _auxiliarySchemas property which is an array of zero or more auxiliary resource type IDs. These would be mapped to their associated LDAP auxiliary object classes.

The Rest2Ldap mapping would specify which auxiliary types are allowed, e.g:

"frapi:opendj:rest2ldap:admin:passwordPolicy:1.0": {
    "superType": "frapi:opendj:rest2ldap:admin:policy:1.0",
    "auxiliaryTypes": [ "frapi:opendj:rest2ldap:admin:passwordValidator:1.0" ],
    "objectClasses": [
        "pwdPolicy", "ds-pwp-password-policy"
    ],

    ...
Comment by Matthew Swift [ 21/Feb/20 ]

The implementation of update/patch will be quite complicated since the resource type can change before and after the change is applied, yet quite a bit of Rest2Ldap's logic assumes that a resource's type is immutable. If an auxiliary resource type is removed too soon then so will its property mappers making it impossible to determine which LDAP attributes should be removed. Likewise, if an auxiliary resource type added too late then so will its property mappers making it impossible to map its LDAP attributes.

One option could be to determine a temporary effective resource type comprising of all the auxiliary types before and after the change is applied, along with their associated property mappers. It may even be possible to precompute this up front when compiling the Rest2Ldap mapping configuration, although this could be harder for resources have sub-types. We also don't want this representation for read operations since it could cause default values for missing auxiliary types' properties to be injected into the returned JSON resource.

Comment by Matthew Swift [ 06/Apr/20 ]

The PaaS is going to use config based password policies so this issue is no longer a blocker. If we are unable to complete the update/patch support in time for 7.0 then I suggest that we take steps to hide the incomplete feature, e.g. by not documenting it.

Comment by Matthew Swift [ 22/Jun/20 ]

Postponing until 7.1.0

Generated at Fri Oct 23 08:20:51 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.