OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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