[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] xpath, urn:oasis:names:tc:xacml:1.0:resource:xpath
I think there is some confusion about the leading "//" and "/" operators in xpath: "//foo" searches the entire document for all <foo> elements "/foo" only returns the outer-most element Note that in xpath, the "root node" of the document is NOT the outer- most element; instead, it is a fictitious node, of which all the "top matter" of an XML document is considered a child. In other words: <?pi?> <!-- comment --> <foo> <bar/> </foo> would create an xpath tree like: / processing-instruction: pi comment: "comment" element: "foo" element "bar" The "/" indicates the root node. So, in an xpath expression, "/foo" indicates all children of the root node which are elements named "foo". The xpath *context* node is denoted by a ".", but this is typically implicit. i.e., "foo" is short for "./foo" (which itself is short for "./child::foo"). Likewise, ".//foo" selects all nodes underneath the current node that are an element named "foo". Note also that xpath expressions are not (typically, anyway) combined by string concatenation, but instead by using relative paths as shown above. > First, let's assume the context node is xacml-context:Request as > stated in sec A.3.15 lines > 4907-4908. i.e. "//xacml-context:Request" - do you agree? (If not, > please specify.) No, I think the context node would be "/xacml-context:Request". Actually, the two are mostly equivalent, unless you have a document like: <xacml-context:Request> <xacml-context:Resource> <xacml-context:ResourceContent> <xacml-context:Request/> <-- a second Request element! In this case, //xacml-context:Request, which selects all Request elements in the document, would return a nodeset with 2 elements in it, but only one is expected. > Now, looking at the specific ResourceMatch fragment you cite below > from section 4.2.4.1 > Rule 1 lines 1166[a241]-1174[a247], my interpretation is that > argument 1 is "/md:record", > which would translate to "//xacml-context:Request/md:record". Agree? No. Using a node as the context for an xpath expression simply indicates what nodeset is returned by ".". This affects relative xpath expressions, like "md:record". The leading "/" in "/ md:record", similar to an absolute path in a file system, is always relative to the root of the document, regardless of the context. In my answers to the rest of your questions, I will assume that instead of "/md:record" you had written "md:record". > If so, then I agree that this would return an empty node-set, since > what we want is: > "//xacml-context:Request/xacml-context:Resource/xacml- > context:ResourceContent/md:record" > Agree? Agreed. If the context-node were the Request, then we would need: "/Request/Resource/ResourceContent/md:record" (xacml-context's omitted) so the ResourceMatch from section 4.2.4.1 would need to be "xacml- context:Resource/xacml-context:ResourceContent/md:record". > If so, then if we were to change "/md:record" to "//md:record" then > I think this would > return what I suggested we want just above for arg 1. Agree? Yes, although it might also return more. > Now for arg 2, my assumption is that the resource:xpath, which we > can probably > assume is either the default context node "//xacml-context:Request" or > "//xacml-context:Request/xacml-context:Resource/xacml- > context:ResourceContent", > either one of which is ancestor to //md:record, and thus would > result in successful > match. Agree? Agreed, but (as explained above) it is not relevant whether or not they are an ancestor to md:record. This is because the leading "//" does not take into account the xpath context. However, to get the meaning that you intended, you would need to do ".//md:record" (note the leading "."). > If we agree to here, then I think 2 things would be needed to > correct this situation > in the spec: > > 1. we would need to change "/md:record" to "//md:record" Agreed, this does return the right result, although it entails a search of the entire document. > 2. we would need to specify what the identifier resource:xpath > really means: > i.e. does it mean the "//xacml-context:Request" node, or the > "//xacml-context:Request/xacml-context:Resource/xacml- > context:ResourceContent" > node. Agree? Agreed. > If so, then I suggest that we take it to mean the latter, which I > think is the intent of > section B.6 lines 5041-5046, which I believe is an identifier for a > namespace, which should > match the namespace of the child of the ResourceContent node. (ex. > lines 1157[a233]- > 1165[a240]) So, resource:target-namespace clearly indicates the expected namespace of the child of the ResourceContent node. Furthermore, lines 5041-5046 make it clear that the XACML PDP MUST confirm that this attribute is correct (* see below). However, there is nothing in that text that indicates to me that the presence of this attribute in the request affects the xpath context node. In fact, if I think about it a bit more, it seems strange to me that the *request* should be able to affect the context node for xpath expressions. Even though xacml assumes that the requests are from a trusted source, but it still seems like a recipe for confusion and possible bugs in the policy. For example, if an xpath expression were used in a policy which did not anticipate the possible presence of a ResourceContent element, it might accidentally return Permit or Fail for a request that did include a ResourceContent element (and resource:target-namespace attribute), because the xpath is now evaluated relative to the ResourceContent instead of the Request element that the policy was expecting. > In fact, if we did that, i.e. specify that "resource:xpath" > effectively sets the > ResourceContextPath to "//xacml-context:Request/xacml- > context:Resource/xacml-context:ResourceContent", > then I think "/md:record" would be correct and we would not have to > do #1 above > to make the example correct. Agree? Agreed except that, as explained above, "/md:record" is not correct. However, a plain "md:record" would be. I hope this e-mail is clear. In order not to confuse the discussion, I am sending a separate e-mail with some questions regarding Resource attributes that were raised as I read through the spec, preparing the answers to this mail. regards, Niko Matsakis
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]