I am exploring a use case where one SailPoint Identity Security Cloud (ISC) tenant acts as the source of truth for identities, and there is a requirement to provision those identities into another ISC tenant.
The second tenant would essentially consume identities from the first tenant and then handle downstream provisioning to applications within its own environment.
I am looking for guidance on the following:
Has anyone implemented ISC-to-ISC identity provisioning between two tenants?
What would be the recommended integration pattern or best practice for this scenario?
Would this typically be achieved using APIs / event triggers / CSV export-import, or via another integration approach?
Any architectural guidance, lessons learned, or reference patterns would be greatly appreciated.
Iāve seen something similar done using the ISC Loopback connector (Source name: Identity Security Cloud Governance) . This source was originally designed to govern the identities in your own tenant, but thereās nothing stopping you from using the identities from another tenant altogether when selecting the API URL and client credentials you would like to use. You would simply just need to use the client credentials & the API URL from the other tenant and select this source as authoritative.
Looking at the 3 points you mentioned, this connector is out of the box and can handle all of your requirements with ease.
Let me know if you have any questions or concerns!
Just to clarify, can this connector be configured so that the source SailPoint ISC tenant acts as the system of record to create and manage identities (not just accounts) in the target ISC tenant?
When you are creating the source in the target tenant, you can select the āAuthoritative Sourceā checkbox and that should allow you to create identities in the target ISC tenant. This will basically match the identities from the source ISC tenant down to your target tenant and allow you to perform provisioning to downstream systems in that tenant.