We're planning on using IdentityMinder for our portfolio of customer facing applications. Sometimes, our customers ask to change the user id of an existing user. What is the best practice for implementing this capability in IdentityMinder?

[Anon Anon]

We're planning on using IdentityMinder for our portfolio of customer facing applications.  Sometimes, our customers ask to change the user id of an existing user.  What is the best practice for implementing this capability in IdentityMinder?

 

We've considered implementing a "clone & terminate" process that would, essentially, copy a user's profile to a new User and UserID but, are concerned that we would loose history with that method.  is there a way to copy history to a new user?

 

Are there reasons to avoid implementing the ability to change a UserID?

 

Are there implementation details, such as not using the UserID as a DN that would be recommended?

 

What have others with similar requirements done?

 

Thanks in advance.

[Anon Anon]

It is my experience that changing the UID is a bad practice.

 

My recommendation is to create an Employee ID or another attribute that is more visible to the end user.  However, the Global UID that is used to link endpoint accounts does not change.

 

The Employee ID can be synced to endpoint systems however and this allows you keep the GUID  the same for all intents and purposes and sync that attribute change to the endpoint systems.

 

This functionality is similar to what you seen when you can log into a website with either an email address, username, or something else.

 

 

[Anon Anon]

Thanks Adam.  You're reply makes a lot of sense.

 

We're thinking of assigning each user an "artificial ID" or GUID.  This will serve as the DN for the user.  We'll have a separate attribute called something like "Login ID" that we'd like to use for authentication.

 

One of the remaining question is; "what happens to the User's history when the Login ID changes?"  Will we be still be able to see the audit history for that user?

 

Anyone have any further thoughts on this approach?

[Anon Anon]

So long as the GUID doesn't change then you should maintain that history.  When you go into VST you can search on that GUID and should see what was requested by or on behalf of that user.  You will just see a different login ID perhaps.

[Efren Yanez]

Hello Gordon

 

As Adam says, change the user id is not a good practice, in fact, this case is evidence that security standards have not been applied or used in the customer site, it is often by legacy applications that make this defect is inherited

 

The best for me would be not rename the user id and apply standards to rearrange applications and / or internal customer processes

If the customer need to change the user id in "Identity Manager" they will surely want to do it also at the endpoint, keep that in mind because is additional work and in some cases it is possible and not others, it depends of the type of connector / application because some do not allow rename  account on the endpoint and you should recreate the account on it.

In the current version of IM, this  functionality doesnt exist(I think), maybe because goes against the best practice. I had a customer implementation with an old IM version and they were requesting the same, in that moment was possible using a rename because the User Store was the same Provisioning Directory, so we used a "legacy package"  published as JIAM API which is in deprecate mode(  https://support.ca.com/phpdocs/7/5655/5655_Deprecation_Policy.pdf ) and this give us  the possibility to rename the Global User and maintain associated accounts, but keep in mind that you will need rename too the user id in you User Store, because newer versions require that repositories (User Store and Provisioning Directory) be separated.

 

According to the CA Technologies documentation they should move API JIAM  to TEWS APIs, but  I still have not seen this update. I opened a ticket for improvement three years ago but has not been materialized

 

Good luck

 

Efren