Antra Saxena:
Currently in our ISC setup, for each new app that is onboarded, the ISC admins create 1 new role per requestable entitlement (so there is a 1:1 mapping between role and entitlement) and that role is made requestable. There is another role per app that assigns the user with the relevant app’s Entra SSO group. This role has an assignment criteria on it to assign the role automatically.
For example, it the app name is Salesforce, all requestable roles will have a name that starts with “Salesforce -” and the role that assigns Entra group will have an assignment criteria that looks at Identity attribute → Assigned Roles → Starts with “Salesforce -”. It also has an assignment criteria that checks if the user has an Entra account.
I don’t like the design of 1:1 mapping between roles and entitlements. It is not the best use of SailPoint roles and they should not be setup in this way. So I am trying to change that by making entitlements requestable.
But the challenge that is that I am unable to find a standard way to setup assignment criteria for the Entra SSO group role. A few options are:
Use Entitlement assignment criteria and enter all requestable entitlements in the criteria - the issue with this is that it is not scalable if there are let’s say 100 requestable entitlements in an application.
Use any other account attribute such as status - but that cannot be a standard and will differ per app. We might even not be able to find such an attribute for some apps.
Not make entitlements requestable and keep using roles but instead of having a separate role for Entra SSO group, add the SSO group entitlement in the same role as the requestable entitlement of the application. Using this, we won’t be able to use the criteria to make sure the user has an Entra account (and would need to assess any other implications of potentially adding them to an SSO group before the account is created).
I am looking for suggestions and ideas on what do you think is the best way to deal with this based on how you might have setup requestable items in your solution. Thanks very much.
1:1 role-to-entitlement mapping is definitely too much overhead. For the SSO group assignment challenge, an approach was shared in this thread that I think sounds very similar to your use case, SSO entitlement nested in a role with assignment criteria based on the entitlements from the app:
Hello everyone,
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 …