[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: second proposal for hierarchical resources
Following is an alternative to "first proposal for hierarchical resources" (http://lists.oasis-open.org/archives/xacml/200304/msg00057.html). This second proposal explicitly deals with all the following aspects of the "hierarchical resource" problem: <Policy> EXPRESSION ASPECTS OF THE PROBLEM: a) How, where xpath-node-match is insufficient, to express matches between a resource description contained in a <Request> with a resource description contained in a <Policy>, where the resource is hierarchical. b) How to express permitted <Actions> for a resource, where certain <Action> identifiers imply other <Action> identifiers. c) How to express permitted <Actions> for a resource, where certain <Action> identifiers require being permitted to perform the <Action> on every node above or below the immediate node being accessed. <Policy> EVALUATION ASPECTS OF THE PROBLEM: d) Define how an "xpath-node-match" in a <Policy> interacts with a <Resource> in a Request that has a "resource:scope" Attribute. e) How to deal with a <Resource> having a "resource:scope" Attribute where the <Resource> can not be described using "xpath-node-match". SECOND PROPOSAL For each Resource Model, a new DataType identifier SHALL be created. For each new Resource Model DataType identifier, a new FunctionId identifier of the form "<DataType>-match" SHALL be created. A textual or functional description SHALL be provided in association with each new Resource Model DataType and "<DataType>-match" FunctionId. This description SHALL include: 1) The syntax to be used for describing a requested resource of this DataType (that is, the format for literal values associated with a particular node in this resource hierarchy). 2) The syntax to be used for describing template or collective descriptions of resources of this DataType (that is, the format for "regular expressions" of this DataType). 3) The rules for matching literal values with templates of this DataType. 4) Optionally (if allowed), rules for matching templates of this DataType with other templates of this DataType (that is, where Requester wants access to the collection of nodes described by a template). 5) The set of or namespace for "action:action-id" identifiers associated with this new Resource Model DataType. 6) The propagation rules for each "action:action-id" identifier associated with this new Resource Model DataType. 7) The implication rules for each "action:action-id" identifier associated with this new Resource Model DataType. 8) The rules for how the PDP shall evaluate a <Request> having a Resource with both a "resource:resource-id" Attribute using this new "DataType" AND having a "resource:scope" Attribute. The rules may simply specify "not supported". Any XACML PDP that claims to support the new Resource Model DataType SHALL implement support for all functionality in the description. Anne Anderson -- 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]