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

*Subject*: **1.1 Work Item: Ordered versions of combining algorithms**

*From*:**Anne Anderson <Anne.Anderson@Sun.com>***To*: XACML TC <xacml@lists.oasis-open.org>*Date*: Fri, 30 May 2003 15:17:31 -0400

Submitted by Anne Anderson and Seth Proctor. The TC voted this week to drop the XACML 1.1 Work Item titled "Deterministic algorithm for combining obligations" because the original sponsor did not submit a proposal. There has been interest in deterministic algorithms for reasons going beyond obligations, so we are now submitting a new proposal. The TC suggested that such a proposal would not be considered "too late" if submitted prior to the 12 June 2003 TC meeting. Problem ======= Often policy writers do not care in which order policies and rules are evaluated, and so may be willing to allow a PDP to perform optimizations that require out-of-order evaluation (based on cached evaluations, network reachability, etc.). A compelling use case is where a hospital emergency room references two policies, either of which is sufficient to return "permit". The first policy says use defibrilator if next-of-kin has authorized; the second policy says use defibrilator if this is life-threatening heart attack. If the next-of-kin policy is unavailable for some reason, do we want to return "Indeterminate" or see if the second policy is available? Our current combining algorithms are appropriate for this set of expectations. In most cases, however, policy writers will assume their policies are being evaluated in order, especially since existing implementations that we know of do so. If an implementation is later optimized to use cached policy evaluations (for example), the policy writer will wonder why their policies are now working differently. Policy writers may also care strongly about order. There may be side effects of policy evaluation (such as obligations). There may be Policies or Rules that the administrator knows are better to evaluate first that the PDP might otherwise try to optimize around. There may be reasons why an unavailable policy should force an "Indeterminate" result. Policy writers may want to be able to test their policies and know they will be evaluated in the same way they were tested. We do not have combining algorithms to meet these requirements. The solution is to define ordered versions of our existing combining algorithms. Since existing implementations probably do not optimize order anyway, the new algorithms can probably be implemented using existing code. Note that several users of Sun's Open Source XACML implementation have requested ordered evaluation of rules and policies, so this is not a theoretical use case. Detailed Proposal ================= Section 2.3: non-normative change line 403: change to Deny-overrides (Ordered and Unordered), line 404: change to Permit-overrides (Ordered and Unordered), Section 10.2.3: add four Mandatory URNs to the Algorithm table urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-deny-overrides urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-deny-overrides urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permit-overrides urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-permit-overrides Section B.10: add four algorithm descriptions The ordered-deny-overrides rule-combining algorithm has the following value for ruleCombiningAlgId: urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-deny-overrides The ordered-deny-overrides policy-combining algorithm has the following value for policyCombiningAlgId: urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-deny-overrides The ordered-permit-overrides rule-combining algorithm has the following value for ruleCombiningAlgId: urn:oasis:names:tc:xacml:1.1:rule-combining-algorithm:ordered-permit-overrides The ordered-permit-overrides policy-combining algorithm has the following value for policyCombiningAlgId: urn:oasis:names:tc:xacml:1.1:policy-combining-algorithm:ordered-permit-overrides Section C: add two new sub-sections to define the new algorithms After section C.1 add a new section called "Ordered-deny-overrides" with the following text The Following specification defines the "Ordered-deny-overrides" rule-combining algorithm of a policy. The behavior of this algorithm is identical to that of the Deny-overrides rule-combining algorithm with one exception. The order in which the collection of rules is evaluated SHALL match the order as listed in the policy. The Following specification defines the "Ordered-deny-overrides" policy-combining algorithm of a policy set. The behavior of this algorithm is identical to that of the Deny-overrides policy-combining algorithm with one exception. The order in which the collection of policies is evaluated SHALL match the order as listed in the policy set. After section C.2 add a new section called "Ordered-permit-overrides" with the following text The Following specification defines the "Ordered-permit-overrides" rule-combining algorithm of a policy. The behavior of this algorithm is identical to that of the Permit-overrides rule-combining algorithm with one exception. The order in which the collection of rules is evaluated SHALL match the order as listed in the policy. The Following specification defines the "Ordered-permit-overrides" policy-combining algorithm of a policy set. The behavior of this algorithm is identical to that of the Permit-overrides policy-combining algorithm with one exception. The order in which the collection of policies is evaluated SHALL match the order as listed in the policy set. Seth Proctor <Seth.Proctor@sun.com> Anne Anderson -- 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

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