Re: [xacml] The Indeterminate flavors question

[rich levinson <rich.levinson@oracle.com>]

Hi Erik,

Maybe I missed something along the way, but I do not understand the meaning
of "combining algorithm value" in Table 7.  Is this defined somewhere?

I do see a number of phrases of the type:

 "... then the policy-combining algorithm specified in the policy set
   SHALL determine the policy set value"

or

"... then the rule-combining algorithm specified in the policy
  SHALL determine the policy value "

One problem might be that the Indeterminate(x) construct is not defined until
section C.1. If we take that as the basis of how the "value of the combining algorithm"
is determined, which makes sense to me, then I think we can conclude that the
rules do not have to be evaluated when the Target is Indeterminate, however,
their effects must be examined in order to determine the type of Indeterminate
that should be returned.

This then becomes the "value" in the left hand column of table 7,  and I think that
everything is consistent.

So, recommendation: have ref in section 7, prior to Table 7, pointing to section C.1
for the defns of Ind(x).

    Thanks,
    Rich

On 4/25/2011 9:22 AM, Tyson, Paul H wrote:

3898C40CCD069D4F91FCD69C9EFBF096063CB8A0@txamashur004.ent.textron.com" type="cite">

Thanks, Erik, for the very clear explanation and examples.

The flexibility of XACML makes it possible to do very strange things, and even without doing anything strange even the simplest policy set can quickly become complicated.  The policy writer already has to think hard about policy structure, combining-algorithms, attribute tests, and the MustBePresent attribute.  He should not have to worry about getting different results depending on whether he happens to put an attribute test in a Target or in a Condition.

But it doesn't appear the TC is inclined to address this problem right now.  Erik's proposal (wd-19 section 7.13, Table 7) seems to be a reasonable approach that will not cause too many surprises.

In the longer term the TC should work out a comprehensive logical framework that explicitly either confirms or denies the "policy equivalence" (or "linearity" as Erik called it) between a policy with a non-empty target and the same policy with an empty target and the attribute tests distributed to the descendant conditions (with appropriate syntactic modifications).  Hal has said the TC has avoided previous attempts to define "policy equivalence", but I assume that was in general, not for this specific issue.

However, I don't think we can avoid the question of whether an indeterminate target should override a "permit-unless-deny" or "deny-unless-permit" combining algorithm on the parent of the indeterminate target.  Erik's example does not include the combining-algorithm of the top policy.  A policy writer who uses one of these algorithms never wants to see "Indeterminate" or "NotApplicable".  Either we must amend wd-19 Table 7 to honor these algorithms, or revise the definition of these algorithms to account for indeterminate targets.  (Note that if we adopted the notion of policy equivalence and evaluated all descendant rules as "Indeterminate", this would not be a problem.)

Regards,
--Paul

-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Monday, April 25, 2011 06:55
To: xacml
Subject: [xacml] The Indeterminate flavors question

All,

Here are some examples which illustrate the points I was trying to make
during the TC meeting last week.

The first example intends to show why it is necessary to evaluate the
children in order to determine the flavor of Indeterminate from a
target.

Consider the following policy:

Policy:
    target: resource-id = printer
            subject-id = alice
    Rule[Effect=Permit]

Assume we have the following request:

Subject:
   subject-id = alice
Resource:
   resource-id = printer

For this request this policy would say Permit.

Now consider this policy:

Policy:
    target: resource-id = bank-account
            subject-risk-level = HIGH
    Rule[Effect=Deny]

This policy would say NotApplicable for the same request as above.

Now, assume that we collect the two policies in a policy set:

PolicySet
   Target: subject-location[MustBePresent='true'] = office
   Policy:
      target: resource-id = printer
              subject-id = alice
      Rule[Effect=Permit]
   Policy:
      target: resource-id = bank-account
              subject-risk-level = HIGH
      Rule[Effect=Deny]

Now, let's evaluate this policy against the example request from above.

The target of the policy set will be Indeterminate because the
subject-location attribute is missing. Now, which flavor of
Indeterminate should it be? It should be Indeterminate{P} since only a
permit could have been produced if the target would not have failed.
And
we know that only if we evaluate the children. Note that simply
scanning
the policy tree for effects would incorrectly conclude that the policy
might have evaluated to a Deny for this request.


Now, there was another issue which was discussed at the meeting, namely
that Paul had an idea that instead of having to actually evaluate all
the children, one could think of the policy is being transformed. I
need
to bring up another example to illustrate that. (I did not want to mix
two issues in the same example policy.)

Consider this policy set:

PolicySet
   Target: subject-location[MustBePresent='true'] = office
   Policy[CombAlg='deny-unless-permit']:
      Target[empty]
      Rule[Effect=Permit]
        target: resource-id = printer
                subject-id = alice
      Rule[Effect=Deny]
         target: resource-id = bank-account
                 subject-risk-level = HIGH


Again, let's evaluate the policy set with the example request from
above. The policy set target is indeterminate, so the policy set is
Indeterminate as a whole. If we would evaluate the children to
determine
the flavor of Indeterminate, we would get Indeterminate{P}, like above
because the rule about bank accounts does not apply.

Now, Paul thought one could rewrite this policy set by adding the
expression from the policy set target in each leaf rule as a condition.
However, I pointed out that it won't give the same result because of
the
combining algorithms. In this case, the rewritten policy would be:

PolicySet
   Target[empty]
   Policy[CombAlg='deny-unless-permit']:
      Target[empty]
      Rule[Effect=Permit]
        target: resource-id = printer
                subject-id = alice
        condition: subject-location[MustBePresent='true'] = office
      Rule[Effect=Deny]
        target: resource-id = bank-account
                 subject-risk-level = HIGH
        condition: subject-location[MustBePresent='true'] = office

Íf we evaluate this policy set against the example request, we get
Indeterminate in both rules because of the missing attribute in their
conditions. However, the 'deny-unless-permit' algorithm is going to
change that to a Deny for the policy which contains the rules, so
overall we get Deny, which is different from the policy set before we
transformed.

The question Paul brought up during the meeting was whether this was
intended. Clearly that is what the spec says happens since the
evaluation tables allow a combining algorithm to make a decision among
several conflicting decisions. I guess what Paul is thinking about is
that there should be some kind of "linearity" requirement, by which
certain properties of the policy are immutable under certain types of
transformations in the policy.

However, there are currently no general requirements on the algorithms
which would guarantee that certain decisions are not overridden. I
don't
think there should be either.

Best regards,
Erik

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php