New Capability: Dynamic Access Roles!

Description

:bangbang: SailPoint® is excited to announce the upcoming release of Dynamic Access Roles in Identity Security Cloud!

Dynamic Access Roles targets the needs of organizations who have specific access requirements and must base their access decisions on multiple and varying factors. Typically, these are organizations with large populations of users with shared access criteria and who have a large number of identities, entitlements, and roles within their environment.

New Capabilities

The initial release of Dynamic Access Roles for Identify Security Cloud in Q4 '24 will allow organizations to leverage dynamic access roles for automatic (birthright) access assignments. This will allow them to implement Identity Lifecycle management use cases such as joiners, movers, and leavers with far fewer roles than were needed previously.

As organizations grow, managing traditional roles becomes more complex, especially in large enterprises where similar jobs require varying access. This often leads to an increased number of ad hoc access requests and manual work items for end users.

Dynamic Access Roles address this by using dimensions, attributes, and criteria to automatically assign the right access to each role member. Each dimension includes an attribute criteria expression that determines if the access should be assigned. For automatic (birthright) assignments, values are sourced from the user’s Identity object, while ad-hoc assignments can be set during role requests.

With Dynamic Access Roles, organizations can simplify role management, reduce manual work, and better meet their evolving access needs.

Example of Dimension Criteria

Example of a Dimension’s Access Selection

Who is affected?

Business+ Customers.
The ISC Business Plus Suite level is required for this feature.

Important Dates

Delivery of the feature will start Monday, October 7th, 2024.

6 Likes

Sounds interesting @PGookin, could be useful for us. :grin:

I do think some more information is needed. Can you share (a link to the) documentation? I wonder how we can use this.

  1. Can we use the search UI/API to easily view these object types and is management of these objects consistent with other objects?
  2. How will this have an effect on certification?
  3. If we add a dimension to a role, will this trigger provisioning to those currently having that role that meet the criteria of this dimension?
  4. If we remove a dimension from a role, will this trigger deprovisioning to those currently have that role that meet the criteria of this dimension and don’t have this access through a different role?
  5. How can we use UI/API to list the dimensions, how can we filter the list?
  6. Are the new APIs consistent to the other APIs in ISC?
  7. If someone request a role, can we limit which dimensions they can request as part of this role?
  8. What are the limitations of this? How many dimensions can we define per role and in total. How many roles can point to the same dimension?
  9. Can we use the search API/UI to search for roles based on dimension?
  10. Can we use the search API/UI to search for dimensions based on role?
  11. What happens if we try to delete a dimension while it is currently assigned to a role and while that role is currently assigned to identities?
  12. Can a role be requested while the dimensions are then assigned automatically through criteria?

The release schedule does not mention dates specifically for sandbox environments and production environments. Can you give this information? Or are they released on all environment levels at once?

Also I would like to emphasize again that timing of these announcements are important. This announcement arrived on the 9th of October, while releasing apparently started on the 7th of October. This means we lost the possibility of properly testing this new functionality before the release to production and perhaps raise issues, concerns or bugs to you and perhaps to communicate and potentially train our relevant end users. Please release announcements before the staging occurs such that we can start planning on this from our side.

Kind regards,
Angelo

4 Likes

Finally…It’s been a long time coming…but finally here. Wow…can’t wait to take this for a spin.
Missing though the Endpoints to allow me to crud this for true automation during org-changes.
Any ideas/updates on endpoint changes allowing me to edit the assignments to the dimensions on my new dynamic role?
Currently I can read the dimensions on the role…but have no info about the access connected to the dimensions on the role.

How will we know if this is available in our environment? is this a new option in the dropdown or ? Secondly will this feature be available to Fedramp customers?

You will notice you have the option to choose the Dynamic Role when creating a role:

/Mikael

Is this to be part of the baseline package, and if not, what is the expected cost/user to licence the module?
I can’t see it in our sandbox, so I’m presuming its a behind a paywall

Hi Phil, this feature is available to customers who are licensed for the Business Plus Suite.

Is this something that is available for devrel tenants?

Hi,
Can anyone post the community documentation url for this dynamic role feature?

Hi Angelo, I apologize for the lack of advanced notice on the release. We do normally provide notice in advance of staging. We have introduced a new process for announcements and the announcement was delayed.

A few general points about dynamic access roles:

  1. The search api/ui is under development. We expect to release search support for dynamic access roles early in 2025 this has not been committed yet.
  2. Dimensions are not stand alone objects they are contained by individual roles. So there isn’t a dimension API. The Role API is used to configure or list a role’s dimensions.
  3. The initial release of Dynamic Access Roles is focused on birthright access. It does not include Access Request ui or api support. We expect to add this support in the first half of 2025 however this has not been committed yet.
  4. Access certification of Dynamic Access Roles is limited in the initial release. Role composition is not supported and role access review is at the role level. Also, dimensional information is not provided to the reviewer. Full certification support is planned for the first half of 2025 however this has not been committed yet.

Here’s a cut at your specific questions:
Q. Can we use the search UI/API to easily view these object types and is management of these objects consistent with other objects?
A. When the search api/ui is available, you will be able to search for roles by dimensions.
Q. How will this have an effect on certification? In the initial release, certification is at the role level only and dimension information is not provided on the review item.
A. We expect to provide full certification support in the first half of 2025 but this is not confirmed.
Q. If we add a dimension to a role, will this trigger provisioning to those currently having that role that meet the criteria of this dimension?
A. Yes. All members of a role will be granted and provisioned with any new access that is added to the role including via dimensions.
Q. If we remove a dimension from a role, will this trigger deprovisioning to those currently have that role that meet the criteria of this dimension and don’t have this access through a different role?
A. No. Currently access removed from a role is not de-provisioned from current role members and this is still the behavior with dimensions. However, we are planning on adding the ability for roles to de-provision access that is removed from a role in the first half of 2025.
Q. How can we use UI/API to list the dimensions, how can we filter the list?
A. The Role list API returns the dimensions for each role. Filter by dimension is not supported yet.
Q. Are the new APIs consistent to the other APIs in ISC?
A. There isn’t a new dimension API. Interaction with dimensions is done using the Role API.
Q. If someone request a role, can we limit which dimensions they can request as part of this role?
A. Access Request is not supported in the initial release. When access request is supported, you will be able to provide dimension attribute values with each request which will be used to determine which dimensions will be applied to the user.
Q. What are the limitations of this? How many dimensions can we define per role and in total. How many roles can point to the same dimension?
A. Each role can contain up to 1500 dimensions. Multiple roles cannot point to the same dimensions. Dimensions are not standalone objects. They are always contained by a role.
Q. Can we use the search API/UI to search for roles based on dimension?
A. Yes. When search support is available this will be supported.
Q. Can we use the search API/UI to search for dimensions based on role?
A. When search support is available this will be supported.
Q. What happens if we try to delete a dimension while it is currently assigned to a role and while that role is currently assigned to identities?
A. The dimension will be removed from all members but it will not be de-provisioned as noted above.
Q. Can a role be requested while the dimensions are then assigned automatically through criteria?
A. This should be supported when access request is supported.
Thanks,
Patrick

2 Likes

Thank you very much for the clear, structured answers Patrick!

Based on your answers, I now wonder:
Suppose I get a role because I meet the membership criteria. I will then only get access from the associated dimensions if I also meet those additional criteria for those dimensions right?
So what If I manually request the role instead of meeting the role’s membership criteria, and it is approved, but in addition I also meet the additional criteria for some dimensions. Will I then automatically get the access of those dimensions as well? Or does manually requesting a role mean that the criteria of the dimensions are not even going to be calculated? In case of the latter, what would happen if I manually request the role and a month later actually meet the membership criteria of that role?

Kind regards,
Angelo

1 Like

Love this in concept so gave it a spin and have an enhancement request. Only associate a user to a dynamic role if they also match criteria of at least one dimension.

The current setup works fine if this is used for traditional job based RBAC, but not all customers are willing to commit to a fully baked RBAC and fall back to application specific birthrights.

Here’s an example:

Say you set up a role called “Metalogix Users”.

Role Assignment Criteria will be CLS = active and ServiceLine in (Home Office, Home Health)

5 Dimensions. Each dimension will be assigned by 1 or more job titles and will have 1 access profile per dimension that will represent the entitlements in app Metalogix to trigger account creation and appropriate access.

I was hoping you would only get the dynamic role if you met assignment criteria AND at least one dimension, but that’s not the case.

All users in the “Role Assignment Criteria” get assigned the role and only users that meet a dimension would actually fire provisioning.

If you could restrict role assignment to also meet at least one dimension, this could be used for role consolidation (5 to 1 in this sample use case) and greatly simplify assignment criteria configurations. As it is setup today, we would misrepresent identities in a role that dont actually have the underlying application.

4 Likes

Any consideration to add the ability to see Identities that are assigned to each dimension? Also, it would help our situation if you added operation under dimension criteria. We have a situation where we would want to exclude identities from the dimension based on a certain attribute value.