New Capability: Role Change Propagation

Announcements Product News
, ,
1

This enhancement is brought to you by :aha: Idea AI-I-51

Description

:bangbang: This release introduces a key improvement to ISC Role Management. Now, when access is removed from a Role definition, the corresponding access can also be automatically removed from users assigned to that Role—helping reduce the risk of over-provisioning and keeping access aligned with intended Role design.

With this release, you can now configure ISC to automatically de-provision access from users when it’s removed from the Role they are a member of. Access that is added to a Role definition will continue to be propagated automatically and will operate in the same manner as it does today.

New Capabilities

Role Change Propagation allows you to configure ISC to automatically remove access assignments from users when access rights are removed from their associated Role definitions.

  • A Global Setting is now available to enable/disable the role change propagation feature.
  • The following access changes are now propagated by ISC:
    • Removal of an Entitlement from a Role
    • Removal of an Access Profile from a Role
    • Removal of an entitlement from an Access Profile included in a Role
    • Removal of a Role’s dimension or removing an entitlement or access profile from a Role’s dimension.

Problem

Currently in ISC, removing access rights from a Role doesn’t automatically remove that access from users assigned to it—leading to potential over-provisioning and increased risk.

Solution

Role Change Propagation provides the ability to configure ISC so that when access rights are removed from a Role definition, the corresponding access assignments are removed from users who have the Role assigned.

Note: This is an optional capability. A Global Setting is available to enable/disable the Role Change Propagation feature.

When the following access rights are removed from Role’s definition, the corresponding access assignments will be removed from users who have the Role assigned:

  • Removal of an Entitlement from a Role
  • Removal of an Access Profile from a Role
  • Removal of an entitlement from an Access Profile included in a Role
  • Removal of a Role’s dimension or removing an entitlement or access profile from a Role’s dimension.

Indication that Role Change Propagation is enabled
Indication that Role Change Propagation is enabled1920×969 49.4 KB

Indication that Role Change Propagation is enabled - Apply Changes
Indication that Role Change Propagation is enabled - Apply Changes1920×844 120 KB

Who is affected?

Role Change Propagation is available for all customers.

Action Required

Role Change Propagation is a configurable capability which is disabled by default. Customers who opt to use this capability must enable the Role Propagation system feature in ISC Global Settings.

Important Dates

Enablement of this capability will begin the week of June 23rd 2025 with the enablement of all staging environments.

Production enablement will begin the week of July 7th, 2025 and is expected to be fully completed by July 21st, 2025.

9 Likes
2

Hi @PGookin,

This is a very useful custom setting, thank you for this announcement. Can the admin expect to see the comment “Role propagation enabled” sign immediately after enabling the feature in Global Settings or there is a task that runs in the background to apply such settings to a tenant? Curious to know :slight_smile:

3

This is fantastic news @PGookin, thank you for picking up this important functionality.

We once tried to automate a workaround to mitigate this functionality gap ourselves as part of our role modelling scripts, but trying to build this outside of the internal ISC processes using APIs turned out to be tricky. Some hurdles we noticed:

  1. Creating certifications after updating the roles and access profiles had issues because certifications is relying on SailPoint’s search database, whose information can be 24 hours delayed compared to the real access people have, as per the Search SLA. Therefore, if we removed access from a role, it could take 24 hours before certifications would reflect it.
  2. Certifications do not allow you to remove individual entitlements if such an entitlement happens to be part of an access profile whose entitlements you all have, even though you have never (indirectly) received this access profile. The automatic detection mechanism of ISC is preventing the option of removing loose entitlements in these cases.
  3. Outside of certifications there were limited options to automatically remove loose entitlements, especially if you did not suppose requesting loose entitlements.

Therefore, we concluded this should really be a process built in the SailPoint servers themselves, so we are happy to see it will soon be there.

With this new functionality. I wonder how you have implemented it. Is this functionality dependent on search? If so, it will not properly work as per the SLA if we make multiple changes within 24 hours.

Suppose a role admin adds an entitlement to a role by mistake, and then removes it again within 5 minutes, will all the added access be removed again in a proper manner? Could there be race conditions here?

When can we start testing this functionality in non-production?

When will the deprovisioning start? The moment we call the API to update the access object, only during identity refresh? Or during a different moment?

If I remove an entitlement from a role, but some people still have this entitlement as part of a different role, will deprovisioning be properly prevented for those people? What if we remove the entitlement from both these roles around the same time?

ISC Supports entitlement hierarchy right? How does this new functionality behave with respect to entitlement hierarchy? As example if I have a child entitlement (Belgium read access) as part of one role and a parent entitlement (Europe read access) as part of another role. And suppose that the corresponding source has minimal authorizations, meaning that if you have Belgium, France and Brazil as entitlements and then get Europe, it will get rid of Belgium and France and just show Europe and Brazil. After all, Belgium and France are children of the parent entitlement Europe, so they should not be added at that point. But the moment you lose Europe, will it automatically add back Belgium and France if you have them in different roles?)

Kind regards,
Angelo

2 Likes
4

If a source does not have a call for removing access, will the system try once and fail, or will it initiate multiple retries on the source?

5

Glad to see this coming. I know that access NOT being deprovisioned when it was removed from a role increased our concern for access creep. Will we see Role Insights recommending access to be removed from roles at some point?