What are entitlements and how can they be enforced?

David Brossard   ·   Thursday, August 31st, 2023

There has been a lot of conversation around what an entitlement is.

When you look at CISSP Rapid Review, they define entitlement as privileges granted to users when their accounts are first created and during the lifetime of the accounts.

This implies a strong governance model and a joiner-mover-leaver process to make sure entitlement assignments are always relevant.

More broadly, IDPro defines an entitlement as “The artifact that allows access to a resource by a principal. This artifact is also known as a privilege, access right, permission, or an authorization”.

There are other definitions of entitlements as well, each with small differences between them. No matter how you define an entitlement, how they can be enforced, and the limitations around them is the same.

The limitations around entitlements are due to the fact they are a very specific identity-centric element in an overall access control strategy.

This means that their over- or under-use can provide a myriad of issues for an enterprise, opening them up to risk.

So, what are the limitations of entitlements and how can they be solved?

Static entitlements vs dynamic authorization

An entitlement, to put it bluntly, is just a label. It’s defined statically and it’s assigned mostly statically.

The entitlement is only as good as the application consuming it. By opposition, in attribute-based access control (ABAC), authorization runs in real-time making it a dynamic solution.

Entitlements are generally granted when the user’s account is created or updated.

They tend to be one-sided.

For example, the entitlements would focus on the user’s identity, their role, and their group. What the entitlement means to a specific system or application eludes the identity and access management (IAM) stack entirely.

This is an important point because it means context is completely absent from the equation.

So, if the user has a certain entitlement, even if it’s something that they shouldn’t have, it is often missed by the IAM system because all it sees is that the user has that entitlement, therefore it must be okay.

As entitlements are assigned once, the following occurs:

1. You need to govern entitlements to remember to add/update/remove them based on the user’s journey. This is often referred to as the joiner-mover-leaver process.
2. You cannot take into consideration contextual information such as time and location (IP address).
3. As we don’t know what the user aims to do at entitlement assignment time, we cannot use action or resource metadata in the entitlements. Most notably, we cannot define relationships between the user (or their metadata) and the item they’re trying to get access to. For instance, a user’s department compared to the item’s department.
4. If a user’s underlying attributes change (e.g. risk score), you cannot quickly and easily update that user’s access

Additionally, entitlements do not scale well.

This is because you have to think about every possible thing a user would want to do or role they’d want to take on, you need to assign as many entitlements.

It is not uncommon for enterprises to end up with 10x more entitlements than users. This is known as role explosion in role-based access control (RBAC) systems and token bloat in token-based systems (think SAML, OAuth, and OpenID Connect).

You don’t always want to have fine-grained entitlements

The more fine-grained you want your entitlements to be the more entitlements you are going to need.

This is because you need to express the richness of whatever is required in the entitlement. Not to mention, every time something changes you have to revisit your entitlements to introduce it; also known as never-ending sudoku.

An example is the following:

When a company sets up their CRM system, they will want to set up multiple roles such as a sales manager, salesperson, and administrator.

Each role will have different things they can do within the CRM system.

The salesperson can create opportunities, but not accounts. Whereas the sales manager can create accounts and the administrator has access to do everything within the system.

As the company grows from a small team to a team covering the whole country. They may want to assign a sales manager to each region.

This is where things can fall apart because you need to create an entitlement for each state and each region.

This can start off easy as there are only fifty states in the United States, but every time something changes, you have to revisit your entitlements to introduce the new change.

As you add new regions the amount of entitlements needed quickly grows as they are required in each region. By the time you end up covering the fifty states with the required roles for each region you could have 630 entitlements.

Everyone has over-provisioned their users

Users that have been over-provisioned with excess entitlements also have to be considered. This is because many people have lots of entitlements that they shouldn’t have.

One of the ways this happens is through access creep.

In this situation, long tenured employees have often gained entitlements over the years to multiple applications that they needed for past roles.

As their roles have changed overtime they have naturally been granted additional entitlements.

However, most organizations fail to remove previous access that is no longer needed or appropriate for their current role.

In the best case scenario, this can lead to additional risk and possible compliance violations.

An example of a violation was recently a hospital in Washington state came to a Health Insurance Portability and Accountability Act (HIPAA) settlement after a breach where several security guards accessed medical records of patients.

In the worst case scenario, this can lead to a damaging data breach.

An example of this was the data breach at Beacon Health where an employee accessed patient records over a period potentially extending over several years which they shouldn’t have had access to.

If the entitlements had been done properly this could have been prevented.

No matter the size of the company, it is easy to get it wrong.

Consider the typical startup where originally employees wear many hats. It is easy to see how as the company grows someone can retain multiple entitlements that they no longer need.

Whereas in a larger organization with thousands of employees, it can be difficult for those in the IT department focused on security to understand which entitlements are needed by which employees.

Where are the standards?

This can get even more complex when you look at standards for provisions across systems and applications.

There is SCIM and it does come with a profile for entitlement management but it’s limited by the fact each system visualizes entitlements their own way with little regard for standardization.

The relationships between roles can open you up to risks

Entitlements don’t take relationships into consideration.

An example of this is each role can have a different level for their approval limit – a CEO could have an approval limit up to a million, a director up to half a million, etc.

In order to do this there has to be a relationship between the different roles and approval amounts.

As ABAC has the visibility into the resources attributes, it can use them within authorization checks inside a policy to determine whether to grant the spending request or not.

However, RBAC does not have the capabilities to do this as they can only consider static roles.

There is no segregation of duty (SoD) with entitlements

Entitlements don’t have the capabilities to segregate roles however many will say that RBAC is capable of SoD with an IAM product enforcing it. This is true if you segregate by role, but not when you start mixing roles or get into more complex situations.

A company may have a sales manager role and a salesperson role that can get a commission. The sales manager assigns the commission to the salesperson when it sells.

Where this can get messy is when our sales manager, Alice, completes a sale on behalf of our salesperson, Elizabeth.

The commission should have been paid out to Elizabeth, but it doesn’t get paid out, it just goes back into the company as there is an entitlement saying sales managers don’t get commission.

Now let’s take that a step further.

There is also a third role within the company which is a trainee sales manager. This is when a salesperson is eventually going to get promoted to a sales manager. They still retain their role as a salesperson, but they also inherit the trainee sales manager role.

The issue with this lies in when Brad, who is a trainee sales manager, figures out that he could assign a commission to himself.

This is where a policy in ABAC should be introduced that says a trainee sales manager can assign commission however they can’t assign it to themselves.

Get more visibility with audit logs

As touched on in the provisions section, a lot of people may have entitlements they shouldn’t have. It means they may not be using the entitlements or they could be abusing them.

An example of this may be that the CEO of the company, Justin, gave the head of marketing, Megan, the entitlements to create a POS on behalf of the company for up to half a million dollars.

Justin doesn’t want oversight, so Megan doesn’t have to get approval from him to spend that money. So Megan can spend fifty thousand dollars and hopefully there is a system in place to keep track of the money spent.

However the spending is not included in the authorization infrastructure and it is stored inconsistently.

When the authorization is externalized from the process it can result in having to do a lot of reconciliations.

However, with runtime authorization in place you can build an audit log of questions and all of the distant decisions with policies.

Now, Megan can spend fifty thousand dollars, but there is a policy in place stating that she can’t spend the money in export controlled countries. Not only would the spending be blocked, but there is also a trail of Megan putting in a request for something she shouldn’t be doing.

This is a powerful tool as Justin can turn around and say, “Hey Megan, I saw that you want to spend $50,000 on something in a country we don’t do business with. What’s up with that?”

This gives you more visibility and control which is a compelling part of a runtime system.

We can help!

Request a demo to see how our Orchestrated Authorization solution can enforce policies, and download our white paper to learn more about how Axiomatics can extend your RBAC model with ABAC.