We have sources configured for lower environments of Oracle ERP and Salesforce. What we have found is that the application teams will from time to time need to copy down the data from production into the lower environments. Doing this we’ve noticed that the IDs for objects such as the user accounts in the source and entitlements may change which causes issues.
We have that ID configured as the “entitlement ID” in the entitlement schema since that’s how the connector was originally set up out of the box and documentation says to not change it.
This made us wonder though how do other companies handle this? We’ve been resetting the accounts and entitlements and rebuilding all of the roles each time and it’s been a lot of work. We tried in the Salesforce source to change the “entitlement id” to name which does stay stable through these environment refreshes but then provisioning access doesn’t work because it relies on that ID value.
Is there any ideas on how to make it so we don’t need to rebuild the roles/access profiles in our tenant each time?
The unstable ID nature of their ‘cloning’ approach shouldn’t be on an IGA stack to address / compensate.
i.e. The chosen approach to clone environments is creating a non-coherent timeline technical debt to be addressed. IDs popping in and out of existence without their respective object life-cycle along a timeline. It’s as if you’re teleporting objects between multiverse.
Review why production data needs to be cloned downward (to what is typically a less controlled environment), and why production data would live in multiple environments. The re-evaluation of the why would hopefully allow them to reassess their options or even maybe address a change management control issue in Production?
Hi @sam-anderson, that’s a challenging problem.
Possibly you could use a “before operation” rule on the account update operation to map the name to the “entitlement id”.
I haven’t tried that so can’t say if it is good approach or not.
I agree with @David_Norris (Terry You) here, that the issue and correction should lie outside of the IAM space. I would wonder why entitlement IDs would change for entitlements that have already been brought down. IE if “ENTITLEMENT A” is in DEV, and was originally a copy of PROD, if it is again refreshed from prod, why does the ID of “ENTITLEMENT A” change again? It almost seems like they are blowing away DEV and copying/cloning PROD fresh, which may be creating new IDs for all items being cloned.
As for what you could do in SailPoint, I think @sam-anderson was on the right track. I do think you may be able to use the name for the entitlements, and bring the ID in as a separate variable. Then in the Before Operation rule (or possibly a before Provisioning if that is what the connector supports) you could move the ID to the proper spot in the provisioning plan. This is untested, and may cause issue with verifying the provisioning (may require an after operation to swap the IDs back so the system shows it completed)
I would recommend that you start the discussion with the teams in charge of the data move and see if there is a better option once they know the issues you are facing.