Why ISC is not truly supporting entitlement hierarchy

Feedback General Feedback
, , ,
1

Hi all, :slight_smile:

When I read that SailPoint Supports entitlement hierarchy, I expected SailPoint being able to handle use cases for applications whose entitlements are hierarchical. Instead what I noticed, is that they only support reading the hierarchy. ISC is not acting on this information.

To give an example. We have an application we want to onboard. Their entitlements follow an hierarchy. Let’s say for simplicity that entitlements represent which ingredients you may manage. For example someone can manage apples, bananas, carrots, bread. However, you can also say someone can manage all fruit, regardless of the type. If we use the UI or API of that application, we can add the entitlement fruit. From that moment if you then look at the list of entitlements, it will not specify apples, bananas, carrots, bread, fruit. It will just show you carrots, bread, fruit. After all, apples and bananas are fruit and therefore don’t need to be mentioned again in the list. If we now try to add the entitlement apple again, we get an error saying the user already has this entitlement (which it inherited through the hierarchy due to fruit being there).

If we now use the web service connector of ISC, we can specify the hierarchy, and after entitlement aggregation, we can see in the UI of ISC, that is knows that fruit is the parent entitlement of apples and bananas and other fruit. We also can see that fruit is a child entitlement of all food.

However, suppose we now have a birthright role, saying every active employee is allowed to manage bananas. One person needs more then just this birthright role, they need to manage all fruit, so they also manually request the role pointing to fruit.

ISC will now deduce that fruit needs to be provisioned, after which the connector will provision this. The server accepts the API call, and says that the new list of entitlements is carrots, bread, fruit. During the next identity refresh, ISC is now thinking that bananas need to be added again. After all, the birthright role points to this, and the list is not specifically mentioning that the user has bananas as entitlement (and ISC is ignoring the entitlement hierarchy here, from which ISC could have easily deduced that the user already has bananas as part of its parent entitlement fruit). So ISC is trying to add bananas again, which the server rejects since it already knows that the user should be able to manage all fruit. During the next refresh, ISC will try again, and again. We can not configure the source such that it will act upon the hierarchy.

Therefore we must conclude that ISC does not truly support entitlement hierarchy. It can only show you the hierarchy.

2 Likes
2

Interesting points.

My take would be that ISC supports entitlement heirarchy for Aggregation/Certification/Policy functionality (READ) and ISC supports multiple types of entitlements (different attributes) in a connected system for provisioning (assignment of entitlements) in target systems (WRITE).

However, the application you are connecting to is not doing access modelling in an optimal way because it is mixing Entitlements at different levels in the same attribute.

What that means is you are attempting to manage 2 competing forms of Heirarchy (ISC and your application).

Im going to explain using L1 (eg Bananas) and L2 (eg Fruit) Entitlements

The L2 Entitlement is not an Entitlement, it does not provide any access, it is just a logical device to assign L1 Entitlements.

It depends what you are using the list for. If it was “give me the list of the fruits which this person has access to”, then yes you would want them mentioned again.

The application API is returning both L1 and L2 Entitlements in the same attribute, and, more than that, is removing lower level Entitlements from that attribute when a higher level Entitlement is assigned to a User. You could say it is returning Roles and Entitlements in the same attribute.

If we used Active Directory as an example, L1 would be a Domain Local Group (with permissions) and it would have as a member the L2, which would be a Global Group (with members). Yes you could add the Account directly to the L1 group, but it wouldn’t be good practice because you would be mixing Entitlement types. And you certainly wouldn’t expect AD to remove the L1 group from the account if the account was added to an L2 group that was itself a member of the L1 group.

1 Like
3

Thank you for your well thought out response @j_place!
I would like to respond to this and see where this goes.

First let me share my desire that applications will standardize themselves where possible, by offering SCIM 2.0 APIs. This will immensely speed up application onboarding and increase security overall by meeting the best practices. I often suggest applications to make their APIs satisfy the SCIM 2.0 protocol.

Taking this into account, fact is that many applications are not meeting this standard, and to be able to connect to them anyway, a key value indicator of an IGA solution is to be able to cater for a reasonable scala of flavours (XML-based or JSON-based API’s, update through PUT (give all account attributes) or PATCH (only specify the delta’s), different methods of pagination et cetera). I hope you agree with me here, and that the main discussion point is if the example I give can be considered a reasonable flavour that should be catered for.

Let’s first address you mentioning that this source is not doing access modeling in an optimal way because it has parent entitlement and child entitlements (which you consider different levels) in the same attribute. The alternative would be to have different attributes for parent entitlement and child entitlement. But there are many examples where this is not happening or where it is (in my opinion) not logical to do this.

  1. If you create a ServiceNow source in ISC, you can see entitlement types group and role. And in the schema of role, you can see it has configured hierarchyAttribute to be roles, showing that entitlements of type role can be parent entitlement of other entitlements of type role.
  2. Another example where different entitlement types and different attributes would not make sense is entitlements describing which folders you have read access to. If you have read access to a folder, you can also read files in its subfolder, and in that subfolder. Treating these folder structure as L1/L2, or as entitlement/role pair would not make sense to me.
  3. Some entitlements can represent how much money you may spend per month. If you have a birthright role in ISC pointing to an entitlement saying you may spend max 1K euro per month, but then you request an additional role pointing to the entitlement of 10K euro a month, then it would make sense for ISC to provision the single value attribute on the source and updating it from 1K to 10K. ISC should know not to again try to provision 1K again, because we should be able to consider 10K the parent entitlement of this child. And once you lose the 10K role again, ISC can then deduce you need to lose the 10K entitlement and downgrade to only the child entitlement of 1K again.
  4. Another example would be entitlements representing in which areas you may operate (only in a specific office in Amsterdam, or in all offices in Amsterdam or in all offices in the Netherlands, or in all offices in Europe, or in all offices worldwide, or all offices in the Netherlands plus an office in Berlin). Calling these entitlements or L1, L2, L3, L4… does not feel correct to me.

Hoping this convinces the fact that it can be perfectly fine for an application to have parent/child entitlements of the same attribute, or at least reasonable enough to accept these applications exists and it would suit ISC to be able to cater for these applications as well.

On a site note, thinking of my first remark that standards like SCIM 2.0 would be preferred, I wonder how SCIM2.0 would solve these types of use cases.

Next bit would be on if it makes sense for this application to omit apples and bananas from the API and only show carrots and fruit as soon as you add fruit as entitlement to the source. I agree with you that this indeed depends on what you are using the list for. For IGA purposes I would say it makes sense not to receive child entitlements in the list if you have already received it by a parent entitlement. Or at least it would be reasonable enough for IGA to be able to work with it. It is more user friendly as you get a minimalist view immediately “Ahh, all the fruit, regardless of which fruits these are and carrots, got it”. Similar would be to only get Europe and Kenya for a clear view and to only get 10K and not also 1K (especially if the account attribute is a single value field). For IGA it also makes sense to only show the most top level values during certification. Only when I want to decide to revoke Europe it will becomes relevant which child entitlements I want to decide to keep. Until then it is enough to be able to click on the entitlement, and see its children and their offspring and to decide to keep it. ISC does not support it like this. It can’t act upon the hierarchy, it can only show it. Note that the minimal approach is also saving data during transfer of account aggregation (assuming you already got the hierarchy by entitlement aggregation). It can be quite chaotic to see all subfolders you inherited appear during account aggregation, which would mean we lose focus, and therefore governance of the thing we try to protect to begin with.

So for clarity, least privilege and to meet security criteria, I think it would make sense for ISC to truly start supporting entitlement hierarchy.

4

Please consider voting for this idea if you agree that ISC should be able to act on entitlement hierarchy during (de)provisioning:

https://ideas.sailpoint.com/ideas/GOV-I-4512

5

I would take this a step futher and say that an IGA solution should be able to accurately and precisely model reality. The reality is that there are a plethora of approaches to authentication and authroization out there. A well-considered object model would be able to handle most of them.

I think back to my days working with RSA Identity Governance and Lifecycle. The way it modeled things was, in my opinion, quite elegant. It almost didn’t make a distinction between accounts and entitlements. The entities involved and their relationships were all treated as objects, meaning they could be associated with metadata. Aggregation sources could reference each other accross business applications, which allowed for modelling scenarios where entitlements for one business application are granted to accounts from another (for example, something like an AD account being made a member of a group that exists only on a local workstation, or an AD account being granted application-level permissions in some business application). Multiple identities could own an account, and accounts that could not be tied to an identity didn’t result in the creation of junk Identities. Instead, they were represented as proper account objects that were simply not associated with any Identity. This made it much easier to track and manage these accounts. IIQ is especially lacking in this area, and I don’t know if ISC is any better.