OASIS eXtensible Access Control Markup Language (XACML) TC

Proposed XACML 1.1 Solution: References to Rules

  • 1.  Proposed XACML 1.1 Solution: References to Rules

    Posted 05-01-2003 20:08
    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