[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposal to clean up xpath
Paul, I am not sure if I understand the proposal, but I have some comments and questions inline. Beyond that, I think now is not the time to redo everything of XPath in XACML. There are reasons why things are like they are so redoing it without careful thought could cause problems. It has also been a goal for XACML 3.0 that it is compatible with 2.0 in the sense that any 2.0 policy can be re-expressed as a 3.0 policy in a fairly straightforward way. All these issues need to be considered carefully. So this would be a major delay for the TC to do this now. The TC has multiple times already decided on a feature freeze and I believe many of us want to finish 3.0. The fact that 3.0 is in a constant limbo is holding back other important work such as improving obligations, a standardized XACML request/response API, standardized attribute retrieval and negotiation, etc. For the rest, see inline. On 2009-11-29 04:15, Paul Tyson wrote: We do not use Content, xpath, or AttributeSelector in our XACML application, but I have been trying mightily to understand how these features could be used in a real business situation. I believe the 3.0 spec needs some significant changes to be useful in this area. I'll give my specific proposals first, followed by a discussion. 1. Deprecate the use of resource-id (and the other *-id XACML attributes) with DataType=xPathExpression. Reserve all *-id XACML attributes for use as "a primary identifier in the domain of the XACML application". I think it's a good proposal to not use "mutating, overloaded" attribute identifiers, so I second this proposal. This already exists as a stand alone issue number. 2. Remove the 3.0 xpath-* functions from the spec. Continue deprecation of previous xpath-* function ids. 3. Remove XPathCategory. The XPathCategory defines the context node of an xpath expression data type value. There is a reason for this attribute, rather than having the <Request> as the context node. Lots of very basic and important implementation optimizations become impossible to do if any xpath can refer to XML node in the whole request. You can search the list for all the discussion. I think I posted about this just a few weeks ago. The short summary of is the by allowing XPaths to span the <Attribute> elements, all attributes must be expressed in actual XML. That means no lazy dynamic attribute retrieval by the context handler for instance. It also means that fragments of the original request cannot be used for multiple request evaluation. Full individual requests must be constructed in XML for each individual request. 4. Specify 3 new XACML attributes with DataType=xPathExpression, for the sole purpose of selecting a sequence of nodes in the Content of their respective categories: urn:oasis:names:tc:xacml:3.0:resource:content-selector urn:oasis:names:tc:xacml:3.0:subject:content-selector urn:oasis:names:tc:xacml:3.0:action:content-selector These attributes take the place of xpath resource-id, and generalize the concept to other categories. 5. Add an xml attribute to AttributeSelector called "ContextAttributeId". When present, this attribute names the attribute in the request context that specifies (by xpath) the context node from which to evaluate the RequestContextPath xpath expression. This eliminates the need for XPathCategory. As I said above, it's a major implementation hurdle to have xpaths span the whole request context. This is why we chose to use an URI XML attribute for identifying the context node, not an xpath. See attached zip file for Example 2, policy 1 and request rewritten with content-selector and ContextAttributeId. There is no need for the xpath-node-match function, because the required test can be expressed in the xpath expression itself, given in AttributeSelector/@RequestContextPath. In general, there is no need for any of the XACML xpath-* functions, because the actual xpath language can be used by AttributeSelector, and the results of the evaluation can be compared using XACML operators. Discussion: In order to make XACML useful for XML content, the full range of xpath expressiveness must be enabled. As currently specified, both the request language and the policy language are severely restricted with respect to xpath. Furthermore, the existing xpath features are difficult to understand and use. The requirements can be stated in 2 points: 1. The AttributeSelector model must allow the policy writer or the request context to specify the starting context node for xpath evaluation. The concept of a context node for xpath evaluation is fundamental to the XSLT processing model, for which xpath was developed. I already proposed a feature to allow the policy writer to specify the context node for AttributeSelector (http://lists.oasis-open.org/archives/xacml/200911/msg00033.html). The current proposal adds a feature to set the xpath evaluation context node from the XACML request context. 2. The Attributes model must provide a way for the PEP to indicate what portion of the XML Content is of interest for the decision. (In the absence of any such indication, the assumption is that the entire content as a whole is of interest.) I have already mentioned the problem of overloading "resource-id" with a different meaning when datatype=xPathExpression. (http://lists.oasis-open.org/archives/xacml/200911/msg00039.html.) That problem is eliminated by deprecating this usage and providing the content-selector attributes. In addition, applications can define their own xpath-datatype attributes and use them for specialized purposes. I believe that when xpath is fully enabled in the core spec using features such as I have proposed, many of the other problems around hierarchical and multiple resources will become less important or will have obvious solutions. Regards, --Paul--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]