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