We are looking for best approaches for Data migration into IdentityNow.
From what I understand, the first step will be to aggregate all our 5 target systems which will lead to all uncorrelated accounts int IDN in each target system.
After this we need to create identities for the accounts so that they can be correlated by aggregating from Authoritative source. At this point how do we ensure that the target system provisioning/update is not triggered.
Manually correlate them or run aggregation from target system again to correlate. What is the best way to correlate accounts?
Overall, is this approach feasible or are there any better possible options?
I would suggest the following approach to load your data.
Create your authoritative source
Create an Identity Profile for the authoritative source. Make sure in Provisioning tab you don’t setup any LCS states to enable/disable accounts and don’t assign any access profiles. You can keep the LCS states disabled.
Aggregate your authoritative source so the Identities get created
Create your target source 1 and setup necessary correlation criteria
Aggregate the target source 1
Verify correlation and if any changes are made to correlation, re-aggregate the source by disabling optimization (via api)
Repeat steps 4 to 6 for each target source you have.
Once data load is complete, you can setup provisioning from Identity Profile and enable any Roles you have for updates/provisioning to happen as usual on Aggregation/Identity Refresh cycles.
To ensure no provisioning/updates are triggered :
Keep LCS disabled in Identity Profile and don’t setup any enable/disable or access profile assignments from it until your initial data load is successful
If you have defined Roles with membership criteria, either keep them disabled or do not attach an access profile to the role.
If you have any workflow defined keep them disabled too.
The plan is to migrate first from target system, however it seems like its not an advisable step.
For our use case, we need to perform some data classification/cleanup before full data migration and hence we wanted to bring over the data first into IDN as uncorrelated accounts and perform some custom processing on the data to generate anomalies before reloading and correlating into IDN.
Is it possible to wipe out all accounts for a source in IDN after first time we bring them over ? Again, here we only intend to wipe out the data at IDN, no impact/change should be propogated over to target system.
Thanks a lot. This is very helpful and comprehensive.
As I mentioned earlier, we do want to bring over data first time into IDN, get it structured as per Sailpoint connector schema, generate proper report and then load it back properly.
Is it possible to wipe out all accounts for a target source without propogating any changes to the target ?
We actually tried /cc/source/reset API with a target source which was deliberately made to fail connection to target system (by changing target source URL), but it didnt work.
Was there an error message when using that API, or did it say it was successful but nothing happened? I ask because that is the correct API for resetting a source (remove accounts and entitlements).
You will make a POST call to {{api-url}}/cc/api/source/reset/48167 where the ID in the endpoint call is the source id that you see in IDN URL when you’ve clicked into the specific Source in the UI (in the below example is 12894):
What is the Target system here, Active Directory ?
Are you working on IdentityNow setup, currently you are not using IdentityNow ? if yes then how are you managing identities currently ?
Yes, we don’t do any provisioning (Manual/Automatic) at all. We just aggregate the data. We can use the API calls to clear the accounts and entitlements as @colin_mckibben mentioned already. Another way is we can simply delete the source even if we don’t like to have it. (I know it doesn’t sound good, but who cares, it’s a one time job rite).
Provisioning happens through Roles/Access Profiles/Workflows/Rules, which we don’t configure at all.
You can bring the identities, accounts as @sharvari mentioned already, do the analysis, do the changes if required, wipe out the data either soft way or hard way.
May I check one more thing on the approach you have suggested.
Currently, we use Role based provisioning for provisiong target systems. So as per the approach you have described, at #6, we will have accounts of the target 1 without any enttitlements or access profiles/roles. After #6, if we aggregate entitlements and create access profiles and roles, after an identity refresh, all accounts will have the required entitlements without any updates/changes propogated to target system. Is that correct understanding?
I would suggest you don’t create any roles before your initial data load but if you create, keep them in disabled state.
When target accounts are loaded, it brings in the associated account entitlements in the source too. But as long as you are not assigning those entitlements to profiles or to roles no provisioning will happen.
Thanks Sharvari. But the expected end-state is that the entitlements must be assigned to the accounts.
We modified the steps accordingly, please see if this is fine -
Create your authoritative source
Create an Identity Profile for the authoritative source. Make sure in Provisioning tab you don’t setup any LCS states to enable/disable accounts and don’t assign any access profiles. You can keep the LCS states disabled.
Aggregate your authoritative source so the Identities get created
Create your target source 1 and setup necessary correlation criteria
Aggregate the target source 1
Verify correlation and if any changes are made to correlation, re-aggregate the source by disabling optimization (via api). Only correlation will happen here. No provisioning to target system
Aggregate entitlements into source and Add roles/access profiles. Since accounts are already correlated at this stage (due to #6), only entitlements will be assigned but no provisioning to target source will be triggered.
Repeat steps 4 to 7 for each target source you have.
Once data load is complete, you can setup provisioning from Identity Profile
We have already enabled Roles in #7 for updates/provisioning to happen as usual on Aggregation/Identity Refresh cycles.
Please note, the account aggregation (#5) brings in accounts and the entitlements associated with these accounts too.
#7 When you aggregate entitlements via Entitlement aggregation it brings in all the entitlements present in the target system. Those may or may not be associated with an account. Also, in this step if you plan to create/bring in roles make sure they are disabled or not associated to any access else it will start provisioning based on your criteria. I would suggest you enable roles at #10.
Okay understand on enabling roles. However, now an afterthought is, we must do Entitlement Aggregation with #5 as we need the entitlements also be assigned to the account.
If the user accounts has entitlements assigned in the target source they are automatically reflected so in IDN too after your account aggregation because Account aggregation brings in the account and it’s associated entitlements as well.
Okay understood. We did test until #5. What we observed was the entitlements are not visible on UI for the account even after the aggregation.
Create your authoritative source
Create an Identity Profile for the authoritative source. Make sure in Provisioning tab you don’t setup any LCS states to enable/disable accounts and don’t assign any access profiles. You can keep the LCS states disabled.
Aggregate your authoritative source so the Identities get created
Create your target source 1 and setup necessary correlation criteria
Aggregate the target source 1
Verify correlation and if any changes are made to correlation, re-aggregate the source by disabling optimization (via api). Only correlation will happen here. No provisioning to target system
Aggregate entitlements into source
Repeat steps 4 to 7 for each target source you have.
Once data load is complete, you can setup provisioning from Identity Profile
Add roles/access profiles. Since accounts are already correlated at this stage (due to #6), only entitlements will be assigned but no provisioning to target source will be triggered. Subsequent updates/provisioning to happen as usual on Aggregation/Identity Refresh cycles.
