Password changes via the Self-Service UI with OpenIDM 5.0.0-SNAPSHOT in conjunction with the LDAP Connector and passthrough authentication (aka Sample2d) do not behave as expected.
Specifically the behavior of OpenIDM with respect to password changes and the ICF 'RunAs' operation does not appear to be correct.
- Password change via Self-Service UI
- Sample2d with the OOTB config works, however it performs a Administrative Reset and not a Password Change on behalf of the authenticated user.
- Sample2d with runAsUser set on the userPassword property within the provisioner fails to perform a Password Change on behalf of the authenticated user. See the following:
The above is caused by the fact that the OpenICF Provisioner requies that the uid attribute be present in the request payload in order to identify the runAsUser. Consequently when the LDAP Modify operation is performed against the remote LDAP server, both uid and userPassword are modified and the OOTB OpenDJ Global ACIs do not allow regular users to modify their uid attribute.
- Progammatic Password Change via openidm script functions.
- It's not possible to provide the X-OpenIDM-Reauth-Password within programmatic calls to openidm.XYZ(). Therfore the Password Change usecase cannot be fullfilled when using a custom endpoint as the entry point.
- Sample LDAP provisioners are missing the runAsUser option
- As a result of 1b) and 2) above, coexisting with various LDAP Password Policies is difficult if not impossible. For example, assume a password policy which dictates that users must change their password within 1hr after a administrative reset:
With the above policy in place on the remote LDAP Server, the OpenIDM Self-Service UI cannot fullfill the Password Change requirement as changes via the Self-Service UI will be handled as administrative resets.