Identity Collectors for Identities

[ChristopherSmi7]

Hello,

I have a question regarding Identity Collections and how an identity is created/deleted/updated.

We have 2 identity collectors, one for Non-Employees (contractors, service providers etc.).  We have another for our direct hire employees.  Both of these are identity creation collectors, where non-employees and employees both have identities in the RSA database.  Both individuals have a UniqueID (first finial of first name, last name), and an EmployeeID (previous employee/non-employee number plus 1).  EmployeeID is our primary key for users.  We collect this value under UserID

Sometimes non-employees are offered positions as direct hires.  At this point, we have a conversion process to convert over the identity and access.  Previously, we had terminated the contractor identity and made all accounts fresh.  This required a lot of work especially as most of the accounts in our environment are manually provisioned.  This would mean the user would have entirely new accounts, entirely new EmployeeID, and entirely new passwords they would have to remember.  We would like to automate this.

Our thought is if we keep the EmployeeID the same across both collectors.  When the time comes, and the user is added to our employee identity source, we would remove the user from the Non-Employee source.  Both collectors collect prior to unification, and therefore the user's identity would see that the Employee source information is there for a given EmployeeID.

Problem is that previously this had worked in our lower environments, however for some reason, duplicate identities are being created.  The deleted Non-Employee identity and the new active Employee identity.

Is this expected behaviour?  That RSA treats the combination of IDC_ID and EmployeeID as a unique identity instead of just the designated EmployeeID

[MostafaHelmy]

If the User ID value is identical and you have unification configured to join both collectors on that common field (USER_ID), then what you are experiencing now is not expected. It should not create any duplicates and simply re-use the existing identity record.

There were a couple of defects around this specific scenario fixed across the different versions. I would recommend you raise a case with RSA support to get to the cause of this.

[DavidHorwath]

Agree with Mostafa Helmy that there has been numerous issues around this historically, so you could be on a version having the issue.

But with that said, there is something called the state "Is deleted".

How I understand it: If an identity enters that state, the unification will be ignored, and all users with the same User ID will be treated as a new identity. So either that is happening in your test environments, or you just mis-configured the unification. Very common error to make, and I do that mistake to often when in a hurry

Otherwise: Contact RSA to help you if that is due to the version you using.

In the organisation I work for, we had to disable the "delete functionality" in this product. Because for legal reasons we want to be sure the identity coming in can be referenced to the same physical person. It is not un-common that a person has short contracts, and re-join maybe 2 times in a 3-year-period.

So maybe we are extreme, but we use a GUID as UserId, and then hide it in all views. And the "employeenr" coming from HR is just put in the attribute UniquId, and hence being the latest reference to "the latest known employeenumber" (here I would love the support for multi-value, but hey...)

And if an employee ends its contract, we put the identity in the state "Is Terminated".

We have not built it yet, but our plan is then to put the identities in the state "Is Deleted" only after a period of X years, depending of what the legal department sees fit (usually after the time period where any crime reaches a state where it is no longer punishable)

After that our plan is (since 2018) that any deleted state should be possible to purge, but for that we all need the help from RSA to implement it. All European countries are in need of such purge function. Because of what I know, the deleted state is permanent, and it is VERY important to remove "as much data possible" before entering that state, as long the product is not adapted to GDPR, and always clears personal information automatically after a defined time.

Oh, this identity issue with duplicates... I could talk forever

[IanStaines · Accepted solution]

Yes I would recommend that you are on the latest version and patch.  There was an issue similar to this fixed in 7.2.0 P05.

I would recommend you open a support case so that we can review this issue specifically. 

[IanStaines]

Christopher Smith‌ did this information help you move towards a solution?

[ChristopherSmi7]

Hello,

Yes this information has been helpful and we will be opening a case shortly.

Thank you

CDS

[IanStaines]

I am marking this thread is resolved.  We will wait for you to open a support case for this issue.