HI Team,
we have a legacy system, we are using to different roles, we can use nested in roles, can we develop same scenario in SailPoint ISC.
Hello @SanjeevCog, Welcome to the community
If by nested roles you mean having one role contain another role, then SailPoint ISC does not currently support role-to-role nesting.
In ISC, the access model is generally: Entitlements → Access Profiles → Roles
A role can contain multiple access profiles and entitlements, and an access profile contains entitlements, but a role cannot directly include another role. If your legacy system uses nested roles to simplify access management, the typical approach in ISC is to:
- Create reusable Access Profiles for common access bundles.
- Add those Access Profiles to multiple Roles as needed.
- Use Role Assignment Criteria or Dynamic Roles to automate role assignment based on identity attributes where appropriate.
So, while ISC does not support nested roles in the traditional sense, similar business outcomes can usually be achieved through a combination of Access Profiles, Roles, and Dynamic Role assignment.
Hi Sanjeev,
Yes, we can reproduce this scenario in SailPoint Identity Security Cloud (ISC), but not as direct role-within-role nesting, because ISC doesn’t support that.
Instead, we can break each nested role into access profiles. Each access profile can only hold entitlements from one source, so a role with entitlements from several applications will need one access profile per source. We then add those access profiles to the ISC role, and the role grants everything the legacy nested role did.
Where several roles share the same access, we can reuse the same access profiles across roles. That keeps the setup easy to maintain.
Hello Sanjeev. @Jerinhrb04& @vamgada covered the main approach well. I would just add a little more detail to help you choose the right ISC model for your use case.
- Role Assignment Criteria → determines who receives the Role based on identity or other configured criteria.
- Role Dimensions on a Dynamic Role → useful when people within the same business Role need different access depending on an attribute such as location or department. SailPoint documents dimensions as providing more granular access within a single Role (Managing Roles).
So if the legacy nesting was mainly for sharing common access, reusable Access Profiles are the closest fit. If it was giving variations of access within the same business role, Role Dimensions are worth a look.
The actual Role → Role hierarchy itself would still need to be flattened when you model it in ISC.
HI Sanjeev,
we cannot use nested roles in the ISC, but you can use the role components (Access profiles/Entitlements) to achieve that requirement . you take the technical entitlements from both legacy roles and assign them as Access Profiles underneath a single target SailPoint Role.
As others have noted only Role > [Access Profiles | Entitlements] hierarchy is possible in ISC. Hence, if your business requires Role > Role hierarchy you will have to use Access Profiles instead of Child roles.
However, if you also need to add “auto assignment” functionality to the Child roles, which is not possible for Access Profiles, you will have to create a role for that.
So, it would look something like this:
Your Requirement: Role-A (Parent) > Role-B, Role-C (children)
What you do in ISC:
- Access Profiles: AP-B, AP-C (these will hold all applicable Access Items)
- Roles:
- Role-B: Has it’s own membership criteria for auto-assignment and AP-B as Access Item.
- Role-C: Similar to Role-B, but for AP-C
- Role-A: Has it’s own membership criteria for auto-assignment and AP-B & AP-C as access items
Also note that Access Profiles in ISC are source specific meaning they can have entitlements from only one source. If your child roles have to have access items from multiple sources, that means you need to create multiple Access Profiles per child Role
I do not recommend trying to build nested role structures in ISC in most circumstances. ISC provides some methods to solve for business needs, but it will not reproduce inherited roles the way you can build them in something like IdentityIQ.
As others have mentioned, Roles and Access Profiles in ISC are flat structures. You cannot build inheritance or nesting within Roles in the way you’re describing. You can build a Role and assign Access Profiles within that Role. However, one critical piece to understand is that an Access Profile is not a Role. It cannot assign entitlements from multiple sources and it does not have its own assignment criteria.
Access Profiles are useful in ISC for modeling or grouping Entitlements from a single source. This can be helpful in a lot of scenarios to help clean up the access model of an application, making it friendlier for requests or easier to manage and re-use packages of access, for example assigning both a group and a role together in something like Service Now.
If you are trying to model the access of a particular type of user or function across more than one source or application, you have to use a Role or combination of Roles, which might then assign the needed Entitlements and Access Profiles. ISC does not have a “nested” or inheritance structure between Roles. You cannot make one Role inherit from a parent Role. However, there are some possible methods to use where you could assign a secondary role resulting from the assignment of a primary role.
Dynamic Roles can help to a limited extent. The main limitation that Dynamic Roles have right now is that the criteria used in the dimensions is limited to Identity Attributes and the comparison operators on those dimensions is very basic.
Say, for example, you have a general “Business Analyst” role and you want to be able to assign an additional AD group to BAs in a specific department. “Department” would probably be an Identity Attribute, so you can make “Business Analyst” a dynamic role, and use the Department attribute as a dimension to assign the additional AD group. The BAs in that department get the standard assignments from the Business Analyst role, as well as the additional AD group from the extra dimension in that Role. (Note, it’s not two separate roles.)
However, what if you need to use a criteria that is not an Identity Attribute? For example, you want to use an account attribute or entitlement from another source… maybe membership in a specific Service Now group that is managed ad hoc (not assigned by an existing role). You can use something the “Business Analyst” role does as criteria in a new Role. For example:
Role “Business Analysts” —(assigns)—> “all-business-analysts” distribution group.
Role “Business Analysts SNOW” uses “all-business-analysts” entitlement as membership critera plus the group from Service Now as membership criteria.
In this scenario, a BA that was also added to the group in Service Now will have two Roles with the entitlements of both.
Another approach, if the assignment of the secondary Role needs to be based on the assignment of the primary Role would be to use a transform with VTL to set an Identity Attribute for the second Role to use. I suggest using this only sparingly.
The bottom line is that ISC’s Role structure is not meant to be nested. It is not meant to be designed around the idea of child roles inheriting either their criteria or entitlements from parent roles, and it is better to go into your implementation with ISC’s paradigm rather than trying to force fit nested behavior from your legacy system to ISC. Dynamic Roles can address a lot of the common reasons for nested roles, but not all of them. Other approaches can lead to maintenance nightmares if overused or used incorrectly.
Hi @SanjeevCog, welcome to the SailPoint Developer Community!
As the replies above confirm, ISC roles cannot contain other roles, so moving a nested model to ISC means flattening the hierarchy. I would do it in this order:
- Resolve each legacy parent role to its effective access. List every entitlement it grants, including what it gets through its child roles, and group the list by source.
- Turn each child role into access profiles, one per source it touches, because an access profile holds entitlements from a single source (Managing Access Profiles). Keep access in access profiles rather than adding entitlements directly to roles. When a child’s access changes later, you edit one access profile and every role that uses it follows.
- Decide whether each child still needs to be a role. If it is only ever granted through its parent, the access profiles are enough. If it is also assigned or requested on its own, create a role for it that holds the same access profiles.
- Rebuild each parent as a role that holds its children’s access profiles plus any access of its own, and move the legacy assignment logic into role criteria. Criteria can check identity attributes, account attributes, or entitlements on a source (Automating Role Assignment). The criteria schema in the Roles API nests only three levels deep, so very complex legacy logic may need simplifying.
- Look for children that exist only because one job needs different access by department or location. A single dynamic role with dimensions can replace them. Dimensions use identity attributes that you enable for them (Managing Roles).
If one role must be assigned only to holders of another, its criteria have to check an entitlement the first role provisions. That entitlement only counts after an aggregation reads it back into ISC, so the second role arrives later than the first.
When an identity stops matching a role’s criteria, ISC removes the role and its access but leaves the source accounts in place (Automating Role Assignment).
For a worked example of dimensions, see Reduce Role Sprawl with Dynamic Access Roles in ISC. For when to use an access profile versus a role, see Should I use access profiles or roles?.
If you share one parent role with its child roles (names and what each grants), we can map it through these steps.