[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WI#9 Proposal: policies referring to hierarchical resources
Contents
========
Problem statement
Schema for describing hierarchies
DataType for describing nodepaths
Functions for operating on hierarchies
Issues
Problem statement
=================
XACML 2.0 Work Item #9 addresses the problem of a policy writer
who wants to control access to elements in a hierarchical
resource. The writer does not want to have to specify access
conditions on each element in the resource individually. For
example, the writer wants to say:
grant read access to any element in the hierarchy below
/a/b/c"
and not
grant read access to /a/b/c/d
grant read access to /a/b/c/e
grant read access to /a/b/c/d/f
....
Schema for describing hierarchies
=================================
Whenever a policy writer uses any of the special functions for
matching hierarchical resources, the Request Context MUST
(notionally) contain a "urn:oasis:names:tc:xacml:1.0:recource:resource-content"
Attribute that contains a Hierarchy element instance. The schema
for describing a Hierarchy element follows.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:oasis:names:tc:xacml:2.0:hierarchy-schema" xmlns:xs="http://www.w3.org/2001/XMLSchema";; xmlns:hs="urn:oasis:names:tc:xacml:2.0:hierarchy-schema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- -->
<xs:element name="Hierarchy" type="hs:HierarchyType"/>
<xs:complexType name="HierarchyType">
<xs:sequence>
<xs:element ref="hs:Node" minOccurs="0" maxOccurs="unlimited"/>
<xs:element ref="xacml-context:Attribute" minOccurs="0" maxOccurs="unlimited"/>
</xs:sequence>
<xs:attribute name="Root" type="xs:anyURI"/>
</xs:complexType>
<!-- -->
<xs:element name="Node" type="hs:NodeType"/>
<xs:complexType name="NodeType">
<xs:sequence>
<xs:element ref="hs:Node" minOccurs="0" maxOccurs="unlimited"/>
<xs:element ref="xacml-context:Attribute" minOccurs="0" maxOccurs="unlimited"/>
</xs:sequence>
<xs:attribute name="NodeName" type="xs:string"/>
</xs:complexType>
</xs:schema>
The RootName and NodeName attribute values MUST not contain a "/"
character unless it is escaped using "\/". If a RootName or
NodeName attribute contains a "\" character, then that character
MUST be escaped using "\\".
Alternatives considered:
a. NetBeans Filesystem DTD
http://www.netbeans.org/dtds/filesystem-1_0.dtd
http://openide.netbeans.org/nonav/fs/Library.html
X Has no query syntax associated
b. XML schema in which each node in the hierarchy is an element
A Requires a new schema to be constructed for each hierarchy
instance
c. WS-ResourceDescriptionFramework
X Does not help handle recursive hierarchies
(e.g. root/container/container/container; it handles
hierarchies in which each element is a unique name, although
multiple elements may share sub-components). Also, it is so
rich that an XACML profile would strip out almost everything
in the schema.
DataType for describing nodepaths
=================================
DataType="urn:oasis:names:tc:xacml:2.0:data-type:nodepath"
A "nodepath" is a string representing the path from the root of
a Hierarchy instance to a particular Node in the Hierarchy
instance. A nodepath is constructed by concatenating the value
of the Hierarchy "RootName" attribute with the value of each
"Node" element's "NodeName" attribute along the path leading to
the node being specified. RootName and NodeNames are separated
from each other using the "/" character.
Alternatives considered:
a. XPath
X Operates on paths of node tags, not on paths of node values,
so would require creations of a separate schema for each new
hierarchy instance.
Functions for operating on hierarchies
======================================
All return "Indeterminate" if arg2 is not a valid nodepath in the
resource-content Attribute.
- Match any descendant of a given node
Function name: descendant-match
Arguments: 1. nodepath to be tested against descendants of arg2
2. nodepath at root of the subtree in the
resource-content Attribute
Returns: Boolean: True if arg1 string-equals the nodepath of
any descendant of arg2 in the resource-content
Attribute
Function name: descendant-or-self-match
Arguments: 1. nodepath to be tested against descendants of arg2
2. nodepath at root of the subtree in the
resource-content Attribute
Returns: Boolean: True if arg1 string-equals arg2 or the
nodepath of any descendant of arg2 in the
resource-content Attribute
- Match any ancestor of a given node
Function name: ancestor-match
Arguments: 1. nodepath to be tested against ancestors of arg2
2. nodepath in the resource-content Attribute
Returns: Boolean: True if arg1 string-equals the nodepath of
any ancestor of arg2 in the resource-content
Attribute
Function name: ancestor-or-self-match
Arguments: 1. nodepath to be tested against ancestors of arg2
2. nodepath in the resource-content Attribute
Returns: Boolean: True if arg1 string-equals arg2 or the
nodepath of any ancestor of arg2 in the
resource-content Attribute
- Match any specific node
Function name: node-match
Arguments: 1. nodepath to be tested against arg2
2. nodepath in the resource-content Attribute
Returns: Boolean: True if arg1 string-equals arg2
- Match attributes of a given node
Function name: node-attribute-match
Arguments: 1. Attribute or AttributeDesignator
2. nodepath in the resource-content Attribute
Returns: Boolean: True if arg1 type-equals an Attribute of
arg2 in the resource-content Attribute
* This can be used to test that arg 2 has an "owner" Attribute
that matches a specified value.
- Match attributes of ancestors of a given node
Function name: ancestor-attribute-match
Arguments: 1. Attribute or AttributeDesignator
2. nodepath in the resource-content Attribute
Returns: Boolean: True if arg1 type-equals an Attribute of
each ancestor of arg2 in the resource-content
Attribute
* This can be used to test that arg 2 has a "can execute"
Attribute that matches the value of the Attribute in Arg1
Issues
======
1. This does not directly address the issue of expressing "in
order to read node x, the subject must have execute rights to
every ancestor of x." I think this can be addressed in XACML
using "deny" rules as described in my previous e-mail.
2. I'm not sure the "ancestor-attribute-match" function buys us
much. For example, it requires a notional "can-execute"
Attribute on each ancestor that contains explicit Subject
identities in order to be use this to solve the problem in
Issue#1.
3. Can we possibly be the first group to run up against this
problem? Why aren't there suitable XML schemas and functions
already available in some other standard? I have Google'd and
asked, but have not found anything so far.
Anne
--
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]