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.
This way, the user automatically gets the SSO group of the application if they have requested for any entitlement of that application.
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.
I agree with your concern — 1:1 mapping between roles and entitlements doesn’t feel like the best use of roles, especially from a scalability and maintenance perspective.
Making entitlements requestable sounds like a cleaner approach, but I can see the challenge around handling the SSO group assignment in a consistent way.
One thought could be to decouple the SSO group logic slightly from individual entitlements and instead tie it to the application context. For example, if there’s a way to identify that a user has any access related to a specific application (even at a higher level like access profile or app-level grouping), that could be used to trigger the SSO group assignment.
Maintaining a list of all entitlements in assignment criteria definitely doesn’t scale, so avoiding that seems like the right direction.
Curious to know if others have handled this using access profiles or some kind of grouping rather than individual entitlements.
Thanks for bringing this up — interesting design challenge.
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:
Thanks @utkirjonkamiljanov . This is one of the options but as I mentioned in the original post, it doesn’t scale well if an application has a lot of entitlements. It might be difficult to manually add all of them in the assignment criteria and if there are new entitlements in the future, we need to keep make sure the assignment criteria is up to date.
Potentially you can mark one of the source attributes as an Entitlement (with an associated Entitlement Type where necessary for clarity) to indicate that the Identity has an account on that source and then add it to the SSO Role criteria.
Eg. In Salesforce there is a userType attribute. Make userType=Standard an Entitlement called (for instance) Salesforce - Standard User, then add to the SSO Role.
For scaling up, I can see that each application would need the attribute identified on a case by case basis.
For applications for which the account object has a status, then we have a single role that will grant the Entra group for SSO based on this. That covers most of our applications.
