I’m building a role model from entitlements to allow users to request access, but I’m not sure whether I should use access profiles or roles to define the access for the sources. The only differences I see are:
Roles can contain access profiles
Access profiles can be requested via applications (which can allow finer management to define approvers)
Roles can be assigned via automatic assignments
Access profiles are discoverable and roles are not discoverable
What is the state of the art for defining a role model? What do you recommend?
Another option to consider with roles is that Roles can contain access profiles from multiple applications and are handy for complex combinations of entitlements that span over more than one application.
Roles are refreshed with each Auth Source aggregation or Identity Refresh and can also be set to be requested but can’t be grouped as an application.
I wouldn’t say there is an explicit use one or the other, but carefully evaluate the use case of each access request or bundle and there will be some cases where Roles will be better suited and others where APs are better.
Thank you for your reply. The main use case I have in the context I’m working on is that a requested access (role or access profile, I don’t know what to choose) is an access in the provisioned source (no multi provisioning sources), so I guess I need to use access profiles?
Also, isn’t it too confusing for end users to use access profiles AND roles to request access? I mean, maybe I should keep roles only for automatic assignments and use access profiles only for requesting access?
I can’t find documentation from SailPoint describing the state of the art in role modeling in ISC.
Yes access profiles would make sense here, if there is no approval workflow then this can also be auto-assigned through the Identity Profile based on lifecycle state. If there is then simply configure this on the AP.
If you plan on grouping these in Applications, then be aware that this can be a bit frustrating as each edit on the application triggers an Identity Refresh which while running, you will not be able to edit any Applications.
You’re right, Roles are better suited for auto-assignments and it can create a poorer user experience but this can be mitigated with proper change management. Consider running a pilot with a small group of users testing both approaches, this way you can get user feedback and also experience first hand what might work best for you and help you plan ahead for potential future role modelling.
I don’t want to steal @Irshaad_Laher_WS solution thread, so despite I’m participating here, keep his answer as the solution for this thread which was very complete already.
I just wanted to provide my perspective based on the few cases we’ve solved with roles / access profile so far. Bear in mind that SailPoint changed the hierarchy of items within roles early this year, and we’re still exploring/assessing the benefits of having entitlements nested directly under roles instead of building access profiles to nest them in roles.
Entitlement assignment in one source based on the membership to certain entitlement in another source:
Some applications require the setup of permission sets associated to app groups and dynamically provide membership to the group that enables SSO for that app in the identity provider. The simplest solution: SSO entitlement nested in role that has rule assignment based on the entitlement(s) imported from the app.
Role setup for a team (classic concept of a “role” in RBAC):
All members of a team usually need to access same things across multiple apps whose business owners might be different. Those accesses may evolve over time and entitlements might be required to be granted/revoked from the team. In this scenario it makes much more sense to build and maintain access profiles for each of the apps a team need and nest them under a role that’s dynamically assigned via rules that determine team belonging (e.g. manager, department, cost center, etc). There might be scenarios for which these roles need to be “requestable” (e.g. employee from another department that needs temporary access to the apps to collaborate with team that has the dynamic assigned configured), but this can be also addressed with a combination of access profile granted via Request Center app + role using the dynamic access explained in scenario 1.
As Irshaad mentioned, grouping requestable through Applications might be a bit too frustrating (to save changes no “identity tasks” should be running, available API is still the one set to be deprecated which already has several limitations), however it offers a “catalog view” in the Request Center that might be friendlier to end-users than a daunting navigation across Roles/AP/Entitlements which end-users may not understand. As far as I know, Applications only allow Access Profiles, so although Roles and Entitlements can also trigger approval processes, you may want to use Access Profiles to build the catalog with items grouped under apps.
I hope this perspective help you to decide what’s best for your particular case.