I’m exploring a SailPoint ISC approach to let staff request UAT access from Production. The idea is that a requestable UAT role in production would grant a UAT SailPoint entitlement, and that entitlement would provision an identity/account in the UAT ISC tenant.
One option I’m considering is modeling the UAT ISC tenant as a non-authoritative generic SaaS source in Production and letting Production provision accounts into UAT when the role is approved. And within UAT, have an authoritative SaaS source called Prod Sailpoint with the highest level access profile.
I’m unsure if that’s the recommended approach though.
I am not sure if this setup will work for you or not, but I can share the approach we use. Both our Prod and Sandbox tenants are setup with SSO so identities in both tenants use the same uid for SSO to work in each one (this helps with correlation). Our Sandbox tenant aggregates in HR data from our Sandbox HR sources, which contain copies of the data from Prod. So every user has an identity in both Prod and Sandbox ISC.
We setup two ISC Governance sources, one for each tenant, in our Prod ISC tenant. We used a correlation similar to the correlation listed in the documentation, so each ISC Prod identity has an ISC Governance Prod and and ISC Governance Sandbox account. We make the user levels for each source requestable as needed so users can request access to either tenant through the Prod ISC Request Center. If a user is terminated (in Prod), the Sandbox account is disabled and access is revoked like our other sources.
This pattern can work, but with a couple of guardrails so you don’t blur Prod/UAT responsibilities or create circular dependencies.