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