There is always a point, when an OpenAM user ends up asking the question: ‘but how can my users change their passwords?’. The answer is quite tricky: there are several ways to do this, but you’re going to have problems with almost each one of them. But first things first, let’s see what do we want exactly:
- Show an own form for the user, where he/she can give the old password, new password / confirmation of the new password combo and press the button, which changes the password with help of OpenAM.
- Change the users password in LDAP without enabling the force-reset password LDAP control. (Note this is only important if you use LDAP datastore, JDBC datastore is in early access stage, this article will not cover that).
This second point is not mandatory, but this feature is used often (by the LDAP module for example).
Note: your Directory Server configuration should contain a force-change-on-reset option with true value. The force-change-on-reset mode means, that if the password was resetted by an LDAP administrator, then the user HAS TO change his/her password to be able to do anything.
Note 2: if your DS uses this option, and you’re using the Datastore module (so something that’s not based on the LDAP module), then your module will genuinely fail, if you’re not handling this special case.
So what’s the proper way?
The proper way is when you have the old password, you validate it (by doing a BIND request) to make sure, that the user is who he tell he is. If the BIND was successful, then we execute a MODIFY command in the name of the just logged in user to modify the userPassword field. This is the proper way, because with this logic you are not resetting your password with the help of an administrator, so the force-reset stays false.
The REST API way
The REST API does not have a specific changepassword function, but it does have an update function as I mentioned in my earlier post. This also means, that because you don’t supply the old password, you just can’t reset the password as yourself, it has to run in the LDAP admins name, so this is a force-reset always! So the magic here is that you call the following REST function:
https://<FQDNSSO>/openam/identity/update?identity_name=aldaris& identity_realm=/&identity_attribute_names=userPassword& identity_attribute_values_userPassword=newPass
Doing this as the logged in user
If you do have the users sessionid, then you could call this resource as the user, IF your DS does not forbid modifying the userPassword for example with an ACI. OpenDS by default has the following global-aci:
(targetattr="audio||authPassword||description||displayName||givenName|| homePhone||homePostalAddress||initials||jpegPhoto||labeledURI||mobile|| pager||postalAddress||postalCode||preferredLanguage||telephoneNumber|| userPassword")(version 3.0; acl "Self entry modification"; allow (write) userdn="ldap:///self";)
This will enable you to modify your own password.
Doing this as admin
Since you’re doing this as admin, the password will be certainly overwritten.
The WebService way
The WebService way and the REST API way does not differ from each other, since they are both using the exact same code.
The ClientSDK way
The ClientSDK has several way accessing an Identity, for example using AMIdentityRepository:
SSOToken token = //getting an SSOToken object AMIdentityRepository idRepo = new AMIdentityRepository(token, "/realm"); IdSearchResults results = idRepo.searchIdentities(IdType.USER, "aldaris", new IdSearchControl()); Set identities = results.getSearchResults(); AMIdentity identity = (AMIdentity) identities.iterator().next();
The idea here is to use the setAttributes method to update the desirable attributes and then call the store, something like this:
AMIdentity identity = ... Map attrs = new HashMap(); Set values = new HashSet(1); values.add(newPass); attrs.put("userPassword", values); identity.setAttributes(attrs); identity.store();
The problem with AMIdentity#store is the same as with the update function: you don’t supply the old password for the function, so there is no way, that this could end up without a force-reset. Also this solution worked for me with an IdRepo created with user token.
The AMIdentity class also has a changePassword method, which does exactly what we want, so let’s see some code:
AMIdentity identity = ... identity.changePassword(oldPass, newPass);
but I had one problem with this: when I accessed the AMIdentity from an IdRepo with a usertoken, then I had the following error message:
Permission to perform the read operation denied to id=aldaris,ou=user,dc=opensso,dc=java,dc=net
For me this does not make any sense, since I’m giving the old password and the new one, the username is supplied by the AMIdentity itself, then why do I need read permission and for what?? Anyway, when I did this with admintoken, then everything was working great without force-reset.
The OpenAM console way
There is also a way to change your password with help of OpenAM console. Just point your browser to
I tried it many times, but the Old password field was always disabled for me, so this password change method also sets the force-reset bit…
As you can see there are many ways to change a users password, but the best way I think is to use ClientSDK with AMIdentity#changePassword or LDAP API directly. For testing the pwdReset flag I’ve used the following command:
ldapsearch -D "cn=Directory Manager" -b "ou=forgerock,o=org" -h localhost -p 1389 -w password "uid=aldaris" "pwdReset"
If you don’t need the force-change-on-reset functionality, then probably you can disable it in your Directory Server. If you want to hack, then maybe you can try out to delete the pwdReset attribute with the REST API, maybe it will work, I haven’t tried it.