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