[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed XACML 1.1 Solution: References to Rules
Proposed XACML 1.1 Solution for "References to Rules" Problem Description =================== XACML 1.0 allows a PolicySet to include other Policies and PolicySets by reference, but there is no provision for a Policy to include Rules by reference: all Rules for a Policy must be literally contained in the Policy. Allowing references to Rules could make Policies shorter, allow sharing of Rules between multiple Policies, and allow Rules for a single Policy to be defined by multiple authorities. This extension has been requested by Farrukh Najmi, who is writing an ebXML Profile for XACML. Proposal ======== Allow XACML <Policy> elements to contains references to isolated <Rule> elements, identified by their "RuleId". Proposed Solution ================= Summary: Add a RuleIdReference element to the policy schema along same lines as current PolicyIdReference and PolicySetIdReference elements. The following detailed proposal is fully backwards compatible. 1. Define new element in policy schema: <xs:element name="RuleIdReference" type="xs:anyURI"/> 2. Change definition of PolicyType: <xs:complexType name="PolicyType"> <xs:sequence> <xs:element ref="xacml:Description" minOccurs="0"/> <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/> <xs:element ref="xacml:Target"/> ! <xs:choice minOccurs="0" maxOccurs="unbounded"> ! <xs:element ref="xacml:Rule"/> ! <xs:element ref="xacml:RuleIdReference"/> ! </xs:choice> <xs:element ref="xacml:Obligations" minOccurs="0"/> </xs:sequence> <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/> <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI" use="required"/> </xs:complexType> [! lines were previously: <xs:element ref="xacml:Rule" minOccurs="0" maxOccurs="unbounded"/> ] 3. Changes to specification: -. Section "3.1 Data-flow model", following line 558, "Figure 1-Data-flow diagram", change label on line connecting PDP to PAP: 1. rule, policy, or policy set -. Section "3.1 Data-flow model", lines 567-568 1. PAPs write rules, policies and policy sets and make them [^insert] available to the PDP. These rules, policies, or policy [^insert] sets represent the complete policy for a specified target. -. Section "3.3.1 Rule": Revise 1st paragraph, lines 612-615: A rule is the most elementary unit of policy. It may exist [^delete^^^^ in isolation only within one of the major actors of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ XACML domain. In order to exchange rules between major ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ actors, they must be encapsulated in a policy. A rule can ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^] be evaluated on the basis of its contents. The main components of a rule are... -. Section "3.3.2 Policy": Remove 1st two sentences from 1st paragraph, lines 666-667: From the data-flow model once can see that rules are not [^delete^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ exchanged amongst system entities. Therefore, a PAP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ combines rules in a policy.] ^^^^^^^^^^^^^^^^^^^^^^^^^^^ A policy comprises four main components. -. Section "3.3.2.1. Policy target": Revise last sentence of 3rd paragraph, lines 694-695: Such <Rule> elements inherit the <Target> of the <Policy> in which they are contained or referenced. [^insert......] -. [Section "4.2.3 Example plain-language rules" needs no change. It already says (line 1029) "These rules may be written by different PAPs operating independently, or by a single PAP."] -. Section "5.20 Element <Policy>", replace 2nd paragraph, line 2064-2065: The main components of this element are the <Target>, <Rule> or <RuleIdReference>, and <Obligations> elements and the [^insert............] RuleCombiningAlgId attribute. -. Section "5.20 Element <Policy>", lines 2072-2083 Replace schema fragment for Policy element with new schema fragment listed above. -. Section "5.20 Element <Policy>", change lines 2102-2104: The <Target> element MAY be declared by the creator of the <Policy> element, or it MAY be computed from the <Target> elements of the referenced <Rule> and <RuleIdReference> [^insert..............] elements either as an intersection or as a union. -. Section "5.20 Element <Policy>", lines 2105-2109, reword as follows (consistent with description of <Policy> within <PolicySet>): <Rule> A rule component that is included in this policy. -. Section "5.20 Element <Policy>", add new description after lines 2109: <RuleIdReference> [AnyNumber] A reference to a <Rule> component that MUST be included in the policy. If <RuleIdReference> is a URL, then it MAY be resolvable. -. New Section to follow "5.22 Element <Rule>": 5.23 <RuleIdReference> The <RuleIdReference> element SHALL be used to reference a <Rule> element by id. If <RuleIdReference> is a URL, then it MAY be resolvable to the <Rule>. The mechanism for resolving a rule reference to the corresponding rule is outside the scope of this specification. <xs:element name="RuleIdReference" type="xs:anyURI"/> Element <RuleIdReference> is of xs:anyURI simple type. -. Section "7.6 Policy evaluation", modify lines 2887-2889: A Rules value of "At-least-one-applicable" SHALL be used if the <Rule> or <RuleIdReference> elements are absent, or if [^insert...........] [^^^^plural] one or more of the rules contained in the policy is applicable to the decision request (i.e. returns a value of "Effect", see Section 7.5). -. Section "10.2.1 Schema elements", line 3311 (table following) xacml:RuleIdReference M [^insert.................................] Discussion ========== As I recall the discussions, when we added PolicySetIdReference and PolicyIdReference, we talked about adding RuleIdReference, but felt that it was not needed: we already had enough levels of composable elements. We had just added <PolicySet>, and were very leery of making more additions unless there was a real need. There was no real semantic objection. Please correct me if I am wrong. -- 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]