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: Re: [xacml] Behavior of combining algorithms: Take 2


Actually, the only-one-applicable does not have a problem in this sense.
It is ok for an algorithm to return an error, which only-one-applicable
is designed to do in this case. We cannot force the PDP to always make a
decision in case there are errors in policies. If someone forces that,
then he is essentially making assumptions about the indeterminate result
and treating it as equivalent to a valid decision.

The problem in this example is that the permit-overrides treats the
indeterminate as it was either deny or not applicable since it returns a
deny. The permit overrides algorithm should return an indeterminate if
it gets an indeterminate as input and there is no permit from any of the
other policies.

Erik


Anne Anderson - Sun Microsystems wrote:
> [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.



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