What is an Entitlement Management System? A Brief Overview

The Entitlement Management System (EMS) is responsible for centrally managing, distributing and enforcing authorization policies throughout the Neo-Security Architecture. Moving from a Role Based Access Control (RBAC) system to an Attribute Based Access Control (ABAC) system is possible once the Identity Management System is in place. Having an API Security Service is also helpful when deploying ABAC.

Role Based Access Control has limitations when used for large scale API infrastructures in that operations are often hard to map against roles. This can lead to role explosion, and becomes increasingly hard to maintain over time. The logic necessary to implement proper authorization rules becomes intricate and hard to test. ABAC addresses these problems by generalizing the authorization decision and by allowing policies to be written and maintained out of band.

Authorization is inherently difficult to centralize. The EMS makes it possible to make authorization decisions on different levels as the requests flow through the system.

An example of this could be:

1. The Authentication Services utilize the EMS in order to authorize a user login
2. The Token Service utilize the EMS in order to determine what claims to put in the issued token
3. The API Security Gateway makes a coarse grained access control decision based on the claims in the token
4. The API makes a fine grained access control decision based on the token and the current request

The distributed nature of the EMS makes this possible by providing a framework to make authorization decisions that are evaluated against policies written by security administrators. These policies can be updated at will, changing both the security and the business logic of the entire system.

There are two companion standards used for ABAC. XACML (eXtensible Access Control Markup Language) with its standardized policy language, ALFA (Abbreviated Language For Authorization).

Another alternative is the Cloud Native Computing Foundation graduate project, Open Policy agent (OPA).

If you are using a standard or not using a standard is not the principal concern for an EMS. The architecture is of greater importance since it provides a blue-print solution for a complex problem. Successfully separating the roles of the components involved in the authorization system greatly improves its usability.

The Entitlement Management System contains the following components:

• A Policy Decision Point

  Responsible for making an authorization decision.

• A Policy Enforcement Point

  Responsible for enforcing the decision from the Policy Decision Point.

• A Policy Information Point

  Responsible for enriching the authorization request with additional information on demand.

• A Policy Administration Point

  Responsible for administrating authorization policies.

• A Policy Retrieval Point

  Responsible for distributing policies to Policy Decision Points.

The Policy Decision Point

The Policy Decision Point (PDP) receives an Authorization Request from the Policy Enforcement Point (PEP). The request contains a set of attributes that the PDP will use to evaluate the policy in place. The combination of attributes from the input request, attributes from an external data sources (Policy Information Point) and the policy itself results in an authorization decision. The format of this response depends on the EMS in use but is typically something like permit, deny, allow:true.

Some systems also implement functionality to enrich the authorization response. This could be used to pass additional conditions or instructions for the PEP to act on. In XACML this is referred to as obligations and advice whereas for example OPA handles this natively with its ability to generate arbitrary data as its response.

When used for APIs or the API Security Service, the attributes come from the Access Token. The Token Service is responsible for creating tokens that contain relevant claims that the PDP can use. Some PDPs have capabilities to validate and decode JWTs directly within the policy itself using native functions.

Some implementations of this architecture use a central PDP, but we recommend embedding the PDP next to the PEP to avoid unnecessary latency. This is a very common deployment pattern for OPA where the PDP can be deployed as a daemon together with the service its protecting or even as an embedded library.

The Policy Enforcement Point

The Policy Enforcement Point (PEP) is the enforcing component for the authorization decision. Whenever a new decision is needed, the PEP creates an authorization request and queries the PDP for a decision. It is then up to the PEP to enforce this decision.

The most obvious PEP in the Neo-Security Architecture is the API Security Service. Many gateways already support acting as a XACML PEP. But the PEP should be considered general, and makes sense to place throughout the system. The Authentication Service, the Token Service, The API Security Service and the API itself may all be beneficial places for a PEP, as different levels of authorization decisions can be made in each component.

The OPA Ecosystem lists several PEP components.

The Policy Information Point

Sometimes the request does not contain enough information for the PDP to make an authorization decision. The PDP can then use the Policy Information Point (PIP) to retrieve additional attributes about the user or the context in order to decide if authorizations should be granted.

In OPA, data can also be made available directly to the PDP by pre-loading the data when the decision engine starts.

The Policy Administration Point

The Policy Administration Point (PAP) is where the administrator creates and maintains the policies in the system. All policies are centrally managed, and it is recommended that the PAP aids in unit testing and verification of policies, as well as in authoring policies.

The Policy Retrieval Point

Finally a Policy Retrieval Point (PRP) is a central distribution point where the policies are pushed or pulled from each PDP that requires them. If the PDP is central there is no need for the PRP, but when using distributed PDPs (such as when embedding together with the PEP) the PRP is responsible for updating the system when policies change. A policy should always be signed so that a PDP can verify that it's authentic when updating to a new policy set.

Tokens and Entitlement

The primary source of information when making an Authorization Request is the token used to access the resource. Therefore the contents of the tokens should be carefully designed to help each component make accurate authorization decisions. The Token Service can be considered the first PIP in the system. It connects to the identity sources available and shapes the claims in the token to match the requirements for the APIs it is meant for. Achieving a well designed token with relevant claims is key to building a scalable entitlement infrastructure.

Conclusion

The Entitlement Management System is built on the fact that the IMS reliably can provide identity information. Without the IMS it is orders of magnitude more difficult to implement a centrally managed distributed entitlement system using ABAC.

Attribute Based Access Control provides a more flexible authorization structure than relying on Role Based Access Control as the only mechanism for authorization. It allows the decision to take more context into account when deciding if access should be granted, and can be changed at will using centrally managed policies. This provides benefits both from a security perspective, but also from a business perspective as new business models can be defined using authorization policies rather than having to rewrite custom authorization logic in the affected systems.

The Curity Identity Server provides a powerful claims infrastructure that aids in the authorization decision by providing a relevant set of claims (Attributes) to the PDP.