Should the policy enforcement point send all attributes needed to evaluate a request?

David Brossard   ·   Wednesday, September 27th, 2023

Key Attributes are the basis of an XACML (eXtensible Access Control Markup Language) request. Policy Enforcement Points (PEPs) can send any number of attributes to the PDP (Policy Decision Point).

At minimum, a PEP must send “key” attributes, i.e. the user identity, the resource identity and type, and the action identity.

This creates the minimal viable PEP request.

Can user username = Alice do action = view on resource of type = financial transaction with transaction id = 123?

Derived attributes enrich an XACML request

The PEP can also send derived attributes, which are attributes derived from the key attributes.

For instance, a user’s job title, department, and clearance are all derived from the user’s username or ID.

In the same vein, a transaction’s amount, location, and owner are all derived from the transaction ID.

I call this a fully-qualified request because it provides all the information that is needed from the PDP.

Can user username = Alice with job title = manager and department = sales do action = view on resource of type = financial transaction with transaction id = 123 belonging to department = finance and with amount = 3452?

The one main drawback to sending the minimal viable PEP request is that it requires the PDP be configured with Policy Information Points (PIP) and calls them which could create a possible performance issue.

The two main drawbacks to sending a fully qualified request is that it couples the PEP and the PDP more tightly as the PEP now needs to know which attributes the PDP expects.

It also makes the request bigger and potentially sends unwanted/unneeded attributes.

Using PEPs to send instant attributes

PEPs can also send “instant” attributes, which are attributes that the PEP alone knows such as the IP address of the requesting user, the device type, HTTP headers, etc.

These are the attributes most commonly (easily) sent by the PEP.

Can user username = Alice do action = view on resource of type = financial transaction with transaction id = 123 from IP = 192.168.1.23 and browser = firefox?

How does it relate to PIPs?

PIPs are the bridges that allow a PDP to connect to underlying sources of attributes (user directories, web services, databases) to retrieve missing information (missing attribute values) so that the PDP can reach a decision.

Consider the following:

• Policy: Manager in sales can approve transactions if they are not the owner and if the amount is less than their approval. limit.
• Request: Can Alice approve transaction 123?

In this scenario, the PDP will need to use PIPs to retrieve:

• The user’s job title, department, and approval limit.
• The transaction’s owner and amount.

Attributes are the basic elements of ABAC (attribute-based access control). They are used in policies, authorization requests, and responses.

Attributes describe a situation. They can relate to users, resources, actions, and context.

Attributes are what make ABAC fine-grained.

It is important to know how attributes can be retrieved, whether from a PIP or from the PEP itself, enabling you to find the right balance in your deployment.

Let’s show you more

Axiomatics has more than a decade of experience working with customers to find that balance as part of a flexible and scalable authorization strategy.

Request a demo with our experts to see how our solution can help you achieve the best balance will be for your organization.