[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Hierarhical resources.. part 0.1
Daniel, Thanks for the write-up. I have been working on a revised draft that uses your idea, and expect to issue it within a couple of days. Here is a brief summary. RESOURCE-ANCESTORS: One important difference is that there can't be a single "resource-ancestors" Attribute. We do not allow "bags of bags", and have no functions for operating on them. However, it is possible to define a "resource-ancestor" Attribute (and a "resource-parent" Attribute), and require there to be an instance of this Attribute for each ancestor/parent. A ResourceAttributeDesignator that references the "resource-ancestor" or "resource-parent" Attribute will then return a bag with all the ancestors / parents. I think this is the result you want. XML DOCUMENTS: I have proposed some changes to XML document hierarchy handling, including use of the "resource-id" Attribute with a new "xpath-expression" DataType rather than using the "xpath" Attribute with a String DataType. The reason is that the <Result> elements will need to identity the node to which they refer in a "ResourceId" XML attribute, and the only standard way we have to specify these is with XPath expressions that evaluate (only) to the node associated with the <Result>. Someone suggested we could not define an "xpath-expression" DataType because there is no standard for XPath expressions. But I think we can specify it as being a "string to be evaluated as an XPath expression", just as we have be saying in the specification for Attributes having "#string" types "to be evaluated as XPath expressions". I am also suggesting we require use of the "resource-content" Attribute with XML document hierarchies; it's notional anyway, so can represent whatever document the XPath expression in "resource-id" relates to. ONE REPRESENTATION PER RESOURCE TYPE: I have proposed, unless there is a profile for the given resource type that specifies different handling, that XML document resources SHALL only be handled using the XPath mechanisms, and non-XML document resources SHALL only be handled using the resource-ancestor and resource-parent mechanisms. The reasons for this are: a) Unless we have one representation for a given resource type, policies will not always apply to instances of the resource when they are intended to. b) We do not have any standard syntax other than XPath for representing actual hierarchical structure (resource-ancestor and resource-parent lose all information about the structure of the hierarchy itself other than the "descendant" status of the requested resource). c) XPath is powerful enough that I think it should be available for use with XML documents. I think enterprises trying to write policies about the contents of XML documents will have XPath available. On the other hand, it is hard to specify a standard representation of non-XML hierarchies in XML and it is computationally difficult to create those representations in such a way that XPath expressions can be correctly evaluated against them. REQUESTS FOR MULTIPLE NODES: On the topic of requests for multiple nodes in one Request, I think we all agree that the <Result> elements must be equivalent to those obtained by evaluating access to each node independently. For this reason, I don't think the "scope" Attribute or a "resource-id" Attribute evaluating to more than one node should be visible to XACML policies. I suggest three syntaxes that a PEP could use for requesting multiple nodes (XPath, scope, and your <Requests> idea), but I don't think they should be part of what is presented to the PDP for evaluation: the Context Handler should convert them. This may rule out some types of optimization, so I am eager to hear of any objections (along with suggestions for semantically consistent handling). 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]