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

*Subject*: **Re: [xacml] Combining algorithm combining orders**

*From*:**"Rich.Levinson" <rich.levinson@oracle.com>***To*: Erik Rissanen <erik@axiomatics.com>*Date*: Sun, 26 Oct 2008 20:27:52 -0400

Hi All, In order to minimize any disruption this suggestion might cause (assuming that people even agree with the logic as I am still open to the possibility that I have missed some essential point), I believe there is a fairly simple way to address it for 2.0 and we can consider if it makes sense to combine Policy and Rule in 3.0 after that is resolved. First, I will present a recommendation for consideration, then follow it with an attempt at a little more clarity as to what the problem being addressed is. Assuming that people are familiar with the p-code combining algorithm logic in Appendix C in combination with the rule, policy, and policyset value determinations in Chapter 7 (7.9, 7.10, 7.11) the following should be understandable in that context. Let us start by defining 4 variables (refs are to XACML 2.0 spec): - ruleValue(i) = evaluate(rule(i)) // i(1->n); eg line 5156,
C.1, p 132,, and sec 7.9 Table 4
- ruleEffect(i) = effect(rule(i)) // = 01-binary for Permit, 10-binary for Deny
- policyValue(j) = evaluate(policy(j)) // j(1->m); eg line 5211, C.1, p 133
- policyEffect(j) = and(effect(rule(1->n)) // result = 01 all Permit, 10 all Deny, 00 mix of Permit/Deny
- the block of logic following line 5225 (if (decision = = Indeterminate) ) would now have to take into account the fact that the policy might be only capable of making one type of decision, which would be determined by the value of policyEffect
- policyEffect can easily be calculated when the policy is evaluated at the top of the loop by "and"ing the effect of each rule as the rules get evaluated (e.g. insert something "policyEffect = policyEffect & effect(rule[i])" after line 5156 in rule-combining algorithm)
- now, similar to the rule combining algorithm we could use the same logic as the rule-combining algorithm to determine the result of policy combining
Given the above logic one can readily see that if we take the strict administrative view that if a potential Deny in a Deny overrides should be a Deny, then line 5183 should be return Deny as indicated in first email. If we took a lax administrative view 5183 could return Indeterminate, which effectively introduces the ambiguity previously discussed, which is probably undesirable, but could be included by defining a lax-deny-overrides combing algorithm. i.e. section C.1 actually defines a lax-deny-overrides rule combining algorithm (because line 5183 renders the result ambiguous, unable to determine whether any of the contained rules actually were a potentialDeny). If we now re-visit Erik's original use case: Let's assume policy P1 is (lax-)deny-overrides since it is within a deny-overrides policy PS. As Erik indicated, P1 returns Indeterminate based on existing lax rule-combining, and PS returns Deny based on existing policy combining.I believe this relatively simple change would solve the problems that currently exist, with little or no impact on XACML 2.0 except to say that we would recommend using these combining algorithms that include the policyEffect as part of the logic. However, for 3.0, I think we will probably find that the net effect of this is that the logic of the rule-combining and policy-combining algorithms become equivalent, which removes the need to have 3 separate concepts of PolicySet, Policy, and Rule. At the simplest level a Policy effectively becomes a PolicySet with a rule-combining algorithm, and PolicySets now effectively can contain an implicit "Effect" if all their child Rules and PolicySets have "Effect"s that produce a single result of Permit or Deny. Comments and suggestions welcome. Thanks, Rich Rich.Levinson wrote: 4904297B.4040601@oracle.com" type="cite">Hi All, |

**References**:**Re: [xacml] Combining algorithm combining orders***From:*"Rich.Levinson" <rich.levinson@oracle.com>

**Re: [xacml] Combining algorithm combining orders***From:*"Rich.Levinson" <rich.levinson@oracle.com>

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