Identity Security Cloud now supports account selection in the Access Request flow!
New Capabilities
When a user has more than one account on a source, the requester is prompted to choose which account to provision access to, and likewise, each record of a user’s access includes account data to support access revocation from the appropriate account.
Problem
Until now, access requests were only supported for users who had a single account on a system, but some users (especially administrators and power users) frequently had multiple accounts on a given system. This limitation meant access could not be requested for those users through Identity Security Cloud (ISC). The common customer workaround was to create a separate source instance per account type for every system where this situation occurred, but that created a lot of system overhead and often duplicated thousands of entitlements in their ISC implementation.
Solution
Admins define one source per system and configure their logic to correlate all of a user’s accounts from that source to their identity. At the end of the request submission flow (when applicable), the access requester is then prompted to select the appropriate account from the list of the target user’s correlated accounts. For that account selection, they are shown the attributes marked as the Account ID and Account Name in the source’s account schema.
The My Request record also reflects the account selection, and both requester and requestee can see that component of the request when reviewing the submitted request flow or history. Audit records (e.g., submitted, approved, processed) also capture the account selection detail.
This feature will commonly cater to IT personnel or those requesting on their behalf because IT staff are the most likely to have multiple accounts on a system. However, this feature is for any user who has multiple accounts on any source.
Important Dates
Sandbox Rollout: Week of March 31, 2025
Production Rollout: Week of April 7, 2025
By RSVP’ing to this event you will be reminded of this release prior.
@jennifer_mitchell Can you please help us understand on what would happen now in case of RBAC or automated membership criteria based role assignment, where multiple accounts for the same identity on the same source gets satisfied with the role? Is there a place where we can define this? Is this even configurable on a role level?
Earlier, Since SailPoint used to only pick the first account that it could find on the accounts tab of an identity for a target source, the behavior was pretty annoying where if an identity has multiple accounts on a source, then SailPoint would randomly assign the role to a random account. But now, due to the introduction of this new feature being released, what would SailPoint ISC do?
So how are revokes working? I am testing this in Sandbox and having trouble revoking the entitlement that is in this state (On an Identity with multiple accounts in a source). I have tried the UI and various API version to revoke. It looks like the API is now using /beta/access-requests where I think it was using /v3/access-request before the March update in Sandbox.
I believe that for roles which assign access profiles this would necessitate the configuration of the “Multiple Account Options” configuration within each access profile that contains entitlements from a source where a user could have multiple accounts. While possible this sounds onerous and error prone.
For roles which assign entitlements directly without an access profile is there any way to determine which account receives the entitlement?
Hi @BenNelson -
The revocation functionality is in the final development stages. You can revoke from a certification now and you will soon be able to specify an account native identity or a role assignment ID in a revocation request. Plus that same targeted revocation will be available in the UI for managers, self, admins, and a new access revoker user level. We expect that to be available in May.
The access request flow for multi-account does not rely on the multiple account selection criteria that gets configured on access profiles; that selection is only used in auto-assignment of access through criteria-based roles or lifecycle states. Our research indicated that customers wanted the flexibility for requests to target accounts that might not be the default account selection specified in that config. So we opted to have the requester select the target account for any request operation.
As for the direct entitlement roles and configuring auto-selection of accounts for auto-assignment of the roles, that is work another team is exploring. @PGookin will be leading that effort and can provide better insight to that plan.
Can you please help us understand on what would happen now in case of RBAC or automated membership criteria based role assignment, where multiple accounts for the same identity on the same source gets satisfied with the role?
@Arshad - Automated assignment of a role still works the same as it has in the past - if you specify account selection logic on the access profiles that go into a role and we discover that the user has multiple accounts on the relevant source, we will provision the access to the account that meets the criteria.
As mentioned in the reply above to someone else’s query, account selection logic for auto-assignment of direct-entitlement roles is functionality we are exploring but do not yet offer.
@PGookin Would love to hear what’s coming for handling the scenario of account selecting during auto-assignment of the roles when satisfying membership criteria. Key thing to understand is what happens in below scenarios:
When an identity having multiple accounts on a source satisfies a role having a membership criteria
When an identity having multiple accounts on a source falls out of the membership criteria of a role
In both these scenarios, how do we expect to handle multi account based scenarios.
@jennifer_mitchell Excited to test this feature. We don’t use SailPoint UI for access requests. Would there be an API update as well to handle this usecase?
Would there be an API update as well to handle this usecase?
Yes, there is an update to the access request submission endpoint to support multi-account requests. The API documentation should come out at or around the time the feature goes to GA (so as early as next week; possibly the week after).
It is a non-breaking change, so the existing payloads will still be supported. You’ll only have to use the new payload if you want to submit requests for users with multiple accounts on a source, though you can also use the new payload for users with a single account.
By RSVP’ing to this event you will be reminded of this release prior.
