Change user password using admin credentials using OpenAM Rest API

Tagged: ,

This topic has 4 replies, 2 voices, and was last updated 4 years, 7 months ago by Andy Cory.

  • Author
    Posts
  • #20128
     sumandevin
    Participant

    Hi,

    I have an OpenAM server connected to an external OpenDJ server. I wanted to change an existing user’s password using OpenAM admin credentials through OpenAM Rest API. The user exists in OpenDJ and can be authenticated on OpenAM. I came across the below API to change password:

    curl –request PUT –header “iplanetDirectoryPro: <Admin TokenID>” –header “Content-Type: application/json” –data ‘{ “userpassword”: <new password> }’ https://<OpenAM HOST:PORT>/openam/json/users/<username>

    However, when I run this, it creates a new user with the same information as the existing user and there are 2 users now with the old password and the new password. So, I can ideally log in to this user with both the original password and the changed password. Any subsequent PUT requests changes the password for the newly created user, but the first original password still remains. Also, that user is not added to external OpenDJ, and external OpenDJ user password stays the same.

    Am I missing something here?

    • This topic was modified 4 years, 8 months ago by sumandevin.
    • This topic was modified 4 years, 8 months ago by sumandevin.
    • This topic was modified 4 years, 8 months ago by sumandevin.
    #20133
     sumandevin
    Participant

    My user is part of the external OpenDJ which is configured on a different realm (not the top realm).
    What I see is when I run

    curl –request PUT –header “iplanetDirectoryPro: <Admin TokenID>” –header “Content-Type: application/json” –data ‘{ “userpassword”: <new password> }’ https://<OpenAM HOST:PORT>/openam/json/users/<username>?realm=ultipro

    or

    curl –request PUT –header “iplanetDirectoryPro: <Admin TokenID>” –header “Content-Type: application/json” –data ‘{ “userpassword”: <new password> }’ https://<OpenAM HOST:PORT>/openam/json/realms/<Realm>users/<username>

    It creates a new user in the top realm, with duplicate details.

    #20134
     Andy Cory
    Participant

    Which OpenAM version is this? I’ve never seen that behaviour – in fact, creating a second user in that manner seems impossible with the out of the box OpenDJ schema, since it would result in violation of uniqueness rules on usernames. From your last sentence, do you end up with two users with the same username, one in an external OpenDJ and one in the embedded OpenDJ? If so, there’s something wrong in the configuration – is your external DJ configured in a sub realm? The curl you are using looks to be targeted at the root realm (though DNS aliases may mean this isn’t the case). Even if having two datastores explains the two users, I don’t see any way that request could create a user in any datastore, only update an existing user, though not necessarily in the datastore you think. Could you give more info about your realm and datastore set up?

    -Andy

    #20153
     sumandevin
    Participant

    Hi Andy,

    We are using AM 5.1.1
    We have both external and embedded OpenDJ configured in our OpenAM instance.

    Please disregard the curl request in the first post. I removed the realm query param while replacing the host and username. My users are stored in external OpenDJ. The external OpenDJ is configured on a subrealm and I can see the users in the subjects tab of the subrealm datastore.

    I used both the below curl requests:

    curl –request PUT –header “iplanetDirectoryPro:<ADMIN TOKEN>*” –header “Content-Type: application/json” –data ‘{ “userpassword”: “password123” }’ https://<HOST:PORT>/openam/json/realms/<REALM>/users/<UserName&gt;

    and

    curl –request PUT –header “iplanetDirectoryPro:<ADMIN TOKEN>*” –header “Content-Type: application/json” –data ‘{ “userpassword”: “password123” }’ https://<HOST:PORT>/openam/json/users/<UserName&gt;?realm=<REALM>

    however, both of them create a new duplicate user. I can see the new user in the subjects tab in top realm. Highly possible they got created in the embedded store.
    They are definitely not changing the password of the original user. The password for that user in the external OpenDJ remains unmodified.

    #20182
     Andy Cory
    Participant

    In your subrealm, do you have two datastore definitions, the external DJ and the embedded DJ inherited from the top level realm? If you haven’t explicitly removed the inherited embedded datastore definition from the subrealm, the answer may be yes. In that case, an update to a user called ‘fred’ in the subrealm will cause AM to search in all defined datastores until it finds a matching user. If that ‘fred’ is in the embedded store, then that’s the user that will be updated, not the one in the external store. That doesn’t explain how a PUT to update ‘fred’ in the subrealm could possibly create a duplicate ‘fred’ in the embedded store, though, that doesn’t make sense to me. Does the duplicate user in the embedded store have the same attribute values as the one in the external store?

    What do you use your top level realm for? Best practice is to define subrealms for your user communities, as you have done. So possibly the top level realm isn’t being used at all, in which case you can delete the embedded datastore definition altogether – in both realms. It would be interesting to see what behaviour you get if you can do this.

    -Andy

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?