[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]