Should the Policy Enforcement Point Send All Attributes Needed to Evaluate a Request?

Axiomatics   ·   Wednesday, June 1st, 2016

Key Attributes and Derived Attributes

Key Attributes are the basis of a XACML request.

PEPs can send any number of attributes to the PDP. At the very minimum it needs to 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 a XACML request.

The PEP can also send derived attributes – attributes that are 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. 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?

Pros and Cons

There is one main drawback to sending the minimal viable PEP request:

• It requires that the PDP be configured with Policy Information Points (PIP) and calls them which could create a possible performance issue.

There are two main drawbacks to sending a fully qualified request:

• It couples the PEP and the PDP more tightly as the PEP now needs to know which attributes the PDP expects.
• It makes the request bigger and potentially send unwanted / unneeded attributes.

Instant Attributes

PEPs can also send “instant” attributes – attributes that the PEP alone knows such as the IP of the requesting user, the device type, HTTP headers… These are attributes that are 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?

Policy Information Points (PIP) 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. For instance, if we have the following:

• Policy: managers 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.

Conclusion

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.

This blog has shown how attributes can be retrieved, whether from a PIP or from the PEP itself. Find the right balance in your deployment.