Re: [xacml] Behavior of combining algorithms: Take 2

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

[I did not give the complete diff in the first edition of this comment]

I've diff'd the first algorithm against the standard deny-overrides
below for easier comparison.  I agree that the proposed variants are
better, although I see the use of "onlyOneApplicable" as an equal
problem in the example you give.  Presumably in that case, besides the
PEP getting a response of "Indeterminate", the PAP should get an error
saying "onlyOneApplicable" had failed - this is a failure of policy
design.  With distributed, dynamic policies, it is not always possible
to detect this situation ahead of time statically unfortunately.

Anne

Erik Rissanen wrote On 02/16/07 11:37,:
> I promised to send a variant of the deny overrides
> policy combining algorithm which does not have the "surprising"
> behavior which Olav Bandmann discovered. Here it is:
> 
> Decision soundDenyOverridesPolicyCombiningAlgorithm(Policy policy[])
> {
>     Boolean atLeastOnePermit = false;
>     Boolean atLeastOneIndeterminate = false;
>     for( i=0 ; i < lengthOf(policy) ; i++ )
>     {
>         Decision decision = evaluate(policy[i]);
>         if (decision == Deny)
>         {
>             return Deny;
>         }
>         if (decision == Permit)
>         {
>             atLeastOnePermit = true;
>             continue;
>         }
>         if (decision == NotApplicable)
>         {
>             continue;
>         }
>         if (decision == Indeterminate)
>         {

STD:          return Deny;

>             atLeastOneIndeterminate = true;
>             continue;
>         }
>     }

STD: start omit

>     if (atLeastOneIndeterminate)
>     {
>         return Indeterminate;
>     }

STD: end omit

>     if (atLeastOnePermit)
>     {
>         return Permit;
>     }
>     return NotApplicable;
> }
> 
> The intuition here is that if we get a deny, then it doesn't matter what
> anything
> else evaluated to. In case there was at least on indeterminate, then we have
> to return indeterminate since the result could have been a deny or a permit.
> If there has been no deny or no indeterminate, then we can be sure that
> the result is permit if there was a permit.
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692