Why don’t I get Obligations or Advice back on Indeterminate or Not Applicable responses?
When a policy is being evaluated in XACML 3.0 Policy Decision Points (PDP), Obligations and Advice elements will be ignored for “Indeterminate” and “Not Applicable” results. Only a “Permit ” or “Deny” condition will result in an Obligation or Advice message being returned. This installment of our Question of the Week explores the reason for this behavior.
First, if you are not familiar with the Obligation and Advice elements, please visit our two-part blog entries for an in-depth explanation:
The XACML specification only allows obligations and advice to be returned on either of Permit or Deny. You have to keep that in mind when you build your policies. This is done on purpose per the XACML specification, found here:
7.18 Obligations and advice
A rule, policy, or policy set may contain one or more obligation or advice expressions. When such a rule, policy, or policy set is evaluated, the obligation or advice expression SHALL be evaluated to an obligation or advice respectively, which SHALL be passed up to the next level of evaluation (the enclosing or referencing policy, policy set, or authorization decision) only if the result of the rule, policy, or policy set being evaluated matches the value of the FulfillOn attribute of the obligation or the AppliesTo attribute of the advice. If any of the attribute assignment expressions in an obligation or advice expression with a matching FulfillOn or AppliesTo attribute evaluates to “Indeterminate”, then the whole rule, policy, or policy set SHALL be “Indeterminate”. If the FulfillOn or AppliesTo attribute does not match the result of the combining algorithm or the rule evaluation, then any indeterminate in an obligation or advice expression has no effect.
As a consequence of this procedure, 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.
The XACML specification is structured this way to prevent unnecessary information being returned in a response, and focusing on the message behind the Obligation or Advice.
For example, consider the following policy structure:
PolicySet Main Policy
Policy Allow managers to view documents + Obligation A on NotApplicable
Policy Allow employees to view documents in their own department+ Obligation B on NotApplicable
Policy Allow publishers to view and publish documents+ Obligation C on Permit
This policy set contains three policies, with each containing a hypothetical Obligation element. Let’s assume that we received the following request:
Can Alice the publisher publish Document#123?
Examining the XACML response in this scenario, you’d receive back:
Receiving Obligations back for B and C makes no sense in the context of the access control decision. For Alice the Publisher’s request, all we are concerned about is the Permit response and the Obligation C. The other information is superfluous and not relevant to our decision.
When using Obligations and Advice, it is important to remember that they will only apply to Permit or Deny decisions. This is designed this way on purpose, per the XACML specification.
The “Question of the Week” – an ongoing feature that will tackle technical and usage questions. We’ll have input from our sales engineers and customer relations teams. If you have a question to consider, please send it to email@example.com.