OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: New algorithm proposal


I have a proposal for a new combining algorithm. I don't want to change the core spec at this point, so I suggest we do this algorithm as a separate profile.

The background to this algorithm is that XACML does not allow <Condition> elements at the policy or policy set levels. This turns out to be a significant restriction in practice. I meet it time after time in the real world.

Typically an XACML policy is written by subdividing the request space into recursively smaller policies and rules. The targets at the policy and policy set levels allow matching against constant values, but not matching between two attributes or other more complex expressions.

This is a problem since it is not unusual to require something like that. For instance, someone may want to write a policy which applies only to the internal users of a sub organization, which requires matching the users organization attribute to the organization of the resource. This cannot currently be done at the policy or policy set levels.

For instance, assume that someone wants to write Policy A, which should contain condition A. Ideally the user would like to define this policy:

Policy A:
  Target A
  Condition A
  Children of A...

This is not possible. It would be possible to push down the condition A into all rules within Policy A, but that introduces complexity, and also worsens performance since the condition will not be applied at the higher level in the tree, where it could eliminate a subsection of the policy tree. (Agreed, a smart XACML implementation might find this redundancy and optimize for it, but that complicates implementations.)

Another option is to work around this is to put the desired condition expression in a rule in a policy next to where one would like pu the condition, and use a combining algorithm to deny access if the condition in the rule does not apply.

PolicySet C, deny-overrides
  Policy B
    Rule B2 deny
      Condition NOT A
  Policy A
    Target A
    Children of A...

There are two problems with this. Firstly, the whole is more complex, but that can be managed by a tool. The second problem, which cannot be solved by a tool is that this is not fully equivalent to what the user actually wants to do.

The problem is that if the condition A does not apply, the latter approach returns a Deny instead of a NotApplicable, which the former would do. The problem of this is that the deny will propagate towards the root of the policy tree, putting restrictions on what the other policies can be like since they might be overridden by the Deny. This complicates policy authoring.

So I suggest that we define a new combining algorithm. The id should be:


This combining algorithm accepts only two children, and will return Indeterminate otherwise. If the first child is a Permit, then the result of the combining algorithm is the result of the second child. If the first policy is NotApplicable, then the whole is NotApplicable. Otherwise the result is Indeterminate.

The normative pseudo code looks like this:

Decision onPermitApplySecondCombiningAlgorithm(Node[] children)
  if (lengthOf(children) != 2) {
    return Indeterminate{DP}
  Decision decision0 = children[0].evaluate();
  if (decision0 == NotApplicable) {
    return NotApplicable;
  Decision decision1 = children[1].evaluate();
  if (decision0 == Permit) {
    return decision1;
  if (decision1 == Permit) {
    return Indeterminate{P};
  if (decision1 == Deny) {
    return Indeterminate{D};
  if (decision1 == Indeterminate) {
    // Return the same flavor of Indeterminate as decision1.
    // If decision0 == Indeterminate, use status code
    // from decision0.
    return decision1;
  if (decision1 == NotApplicable) {
    return NotApplicable;

Note that for simplicity I chose to return Indeterminate{DP} in case of an incorrect number of children. We could instead have evaluated the second child to figure out what the possible value from the second policy would have been and adjust the Indeterminate accordingly. But since we are checking for the number of children, it's not sure that there is a second policy. And this is an obvious error that tools or the PDP can check for statically, so it's not worth introducing complexity for.

Also note that the last if statement is a bit interesting. In this case there was an error in the application of the combining algorithm when evaluating the first child, but the second child is NotApplicable. I chose to return the NotApplicable in this case because the whole could never be anything than NotApplicable in any case. But this is a bit different from how for instance a target is evaluated. If a target becomes NotApplicable, the whole is Indeterminate, even if the children in theory could be all NotApplicable. But I figured that since we have the information available, we can as well use it. Alternatively we could skip the whole processing of different flavors of Indeterminate, but since the other algorithms do it, we may as well do it here.

Using this combining algorithm it will be possible to write policy structures which are equivalent to a <Condition> in either a policy or a policy set, without us having to change the core spec. Authoring tools can hide this extra structure from users if desired.

Best regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]