The XACML standard provides a means of returning the reason for an access request denial through the use of the Obligations and Advice expressions, which were added in the 3.0 standard. A comprehensive explanation of Obligations and Advice can be found in our blog entry titledYou are not obliged to follow my advice: Obligations and Advice in XACML part 1. More specifically, an in-depth explanation of how denial reasons can be returned in an Advice message can be found in Obligations and Advice in XACML part 2.

For this Question of the Week’s simpler example, only two definitions are needed in advance:

Obligations are the means by which a Policy Decision Point (PDP) can tell a Policy Enforcement Point (PEP) that a decision is dependent on extra constraints. It is the PEP’s responsibility then to abide by the decision of the PDP only if the extra constraints can be satisfied. One can also think of these extra constraints as commands from the PDP to the PEP.

Advice is similar to obligations and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives. One use of the Advice expression is as a means to tell the PEP the reasons why a request has been denied. To do this, let’s come up with a simple scenario to illustrate how this would work.

Let’s assume that an employee wants to access a document that contains Personally Identifiable Information (PII), such as a social security number or home address. In our scenario, let’s also assume that there’s an organizational policy that states that all employees who access documents containing PII must have had a training course in the proper handling of PII material.

For a digital policy, you may have a rule that states in natural language:

Note that, per theXACML specification for Obligations and Advice, no obligations or advice SHALL be returned to the PEP if the rule, policies, or policy sets from which they are drawn are not evaluated, or if their evaluated result is “Indeterminate” or “NotApplicable”, or if the decision resulting from evaluating the rule, policy, or policy set does not match the decision resulting from evaluating an enclosing policy set. In other words, the rule must be evaluated to DENY if an Advice message is to be returned to the PEP.

The digital form of this policy may look something like this:

Here we are stating that a DENY will be returned to the PEP if the employee’s training status (e.g. PII Handling) does not match the document’s training requirement (e.g. PII Handling). Receiving a XACML response indicating DENY does not provide the PEP with any other additional detail about why the request was denied. Here’s where we can use the XACML 3.0 Advice expression to return additional information to the calling PEP. Using our example, we could construct a message using attribute variables taken from our data dictionary:

When the Effect for this Advice is set to DENY, the message would be delivered to the PEP as this:

Here the variables in the message have been resolved to provide the name of the employee (employeeID) and the training that is required (PII Handling) to access this document. The PEP can then choose how and if this message is relayed to the requestor. The message could also be logged for auditing and troubleshooting.  

Conclusion

In this simple example we have shown one way to use XACML 3.0 Advice messages to return information from the PDP to the PEP. The information that can be returned via Advice is only limited by the robustness of your attribute dictionary and how your policies are crafted. By using XACML 3.0 Advice, you are able to provide additional information to your PEP other than simply PERMIT or DENY.



Leave a Reply

Your email address will not be published. Required fields are marked *