The Entitlement Management System

The Entitlement Management System

architect

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.

Entitlement Management System

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
EMS integration overview

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) and ALFA (Abbreviated Language For Authorization). There are also non-standard solutions that provide similar structures such as 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 Entilement 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 Descision Point (PDP) receives an Authorization Request from the Policy Enforcement Point. The request contains the Action, the Context and Subject attributes and the Resource that is being targeted. The PDP then evaluates the current policies and responds with an Authorization Response of either allow or deny. Some systems also implement obligations, in which the PDP can respond with an obligation or allow if... leaving a condition that the caller must fulfill in order to allow.

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.

Entitlement Management System

Obligations

In the Curity Identity Server, Authentication Actions can return an obligation that the user must fulfill in order to be allowed to the next step in the authentication flow.

Some implementations of this architecture use a central PDP but we recommend to embed the PDP next to the PEP to avoid unnecessary latency.

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 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 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.

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.


Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds