New Capability: Multi-Account Support!

Announcements Product News
, , ,
1

Description

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.

Select Accounts
Select Accounts2968×896 160 KB

Approvers are shown the account selection as part of the Details overlay on the approval item.

Details
Details2954×1848 355 KB

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.

Requested Accounts
Requested Accounts1920×1194 151 KB

Who is affected?

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

:bangbang: By RSVP’ing to this event you will be reminded of this release prior.

Update: API Details

If you have scripts which use the create-access-request | SailPoint Developer Community endpoint, there is an update to the request payload that must be applied to take advantage of this new functionality. Refer to that API documentation for details. The new payload has been applied as a non-breaking change, so existing scripts will continue to function as they always have, supporting requests for users with one account on the target system.

12 Likes
2

Very excited to have this and start testing out in the Sandbox environment.

3

A missing feature we only had in IIQ! Awesome Work.

Now the question is, are we planning to have the same function as the Account Selection Rule have?

Thx!

3 Likes
4

Is there a way to force which account the entitlement is provisioned on?

5

@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?

3 Likes
6

Hi @jennifer_mitchell,

I tested the multiple account selector and really liked it! Thank you for this feature :slight_smile:

1 Like
7

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 have logged a ticket on this to support.

8

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?

2 Likes
9

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.

4 Likes
10

Hi @jmutschlerProtiviti -

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.

11

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.

12

Thanks for the response @jennifer_mitchell

@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:

  1. When an identity having multiple accounts on a source satisfies a role having a membership criteria
  2. 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.

Thanks,
Arshad.

3 Likes
13

@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?

14

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.

Check here for updates in the next couple of weeks: create-access-request | SailPoint Developer Community. (The beta, v3, v2024, and v2025 versions will all support the new option).

15

This is great news @jennifer_mitchell ! I do have two questions:

  1. Will the ServiceNow request catalog integration follow suit with this new feature?
  2. Are you working on supporting the creation of accounts for someone who already has one or more accounts? I know this is trickier because of needing to support varying Create Account configs / Attribute Sync configs, but it would be AMAZING if multiple accounts were supported in this regard as well!
5 Likes
16

Hi Jennifer,

I have a codebase that currently uses the legacy “v3/access-requests” API endpoint to send a payload to assign an Entitlement to an Identity. I’m being asked to use this new feature / new API to assign the Entitlement directly to an Account. (Previously we had to duplicate Entitlements into the same source as the (non-authoritative source derived) Accounts and send a payload which includes the Identity ID and the Entitlement ID). Does the new feature / API mean that it is possible to send Access Requests which include Account IDs and Entitlement IDs instead?

If yes, are there going to be any examples added to the collection for adding Entitlements to Accounts? Everything seems to be geared toward ACCESS_PROFILE in the examples.

As you discuss the feature, you seem to be touting that it addresses the specific situation of an IT user having multiple accounts on the same source. However, I’m being told that the new functionality / new API is going to make it possible for me to send Account-Specific access request payloads to add an Entitlement. Is this right? There seems to be some confusion about the basic functionality.

Regards,

Trey Carroll

17

Hi @jennifer_mitchell - Have the same question specifically on account creation. How can we address account creation aspect?

18

@jennifer_mitchell what does this do to “best practice” for the situation where multiple accounts exist on a single source? Would SailPoint now say that it is fine to have multiple accounts on a source, is it better to create multiple sources, or is there no guidance on best practices here? You do you, and we will try to make ISC bend to your needs, kind of deal?

19

@jennifer_mitchell - I have also seen multiple accounts in source causing issues with Attribute sync in the past. Any changes to that behavior with this functionality?

20

Hi Sreejith -

Re: account creation, at this time, we don’t have the capability of supporting multi-account creation. The guidance is that to use this multi-account access request functionality, you need to have some other flow for creating secondary accounts (outside the access request process).

At some point in the future, we do anticipate supporting account creation, but there are other complicating factors in that functionality, and this feature was not built to address that flow.

You asked about attribute sync as well - I would need to do some testing/investigating to understand the full impact of multiple accounts on attribute sync, so I can’t speak to that offhand. I’ll try to get back to you when I know more.