Re: [xacml] CD-1 issue #11: strictness of xpath definition

[Erik Rissanen <erik@axiomatics.com>]

Rich,

I maintain that the paradigm of matching xpath expressions with regular 
expressions is flawed. XPath is a matching language in itself, and we 
should not make an attempt to define another layer of string matching on 
top of it because:

1. It is a complex task to do so, and it is very easy to make a mistake.

2. It is wasted effort since there are already xpath matching functions 
in XACML which work perfectly well.

I agree that it could be a good idea to suggest how an implementation 
could construct the xpath expressions in order to help implementers and 
users alike, but that should not be normative. But I think that kind of 
advice belongs to some implementation guide document, rather than the 
standard specification itself.

Best regards,
Erik


Rich.Levinson wrote:
> Significant changes have been proposed to the hierarchical/multiple 
> profiles and some related changes in the core as well as outlined in 
> these messages:
> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00001.html
> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00000.html
> as well as the OGC Engineering Report document attached to the first 
> message.
>
> Speaking for myself and as member of the XACML TC, I much appreciate 
> the effort that went into the analysis of the core spec and these 
> profiles by the GeoXACML group, and particularly, Jan Herrmann (Chair: 
> GeoXACML SWG), who presented this material to us this summer (info for 
> pres in these minutes):
> http://lists.oasis-open.org/archives/xacml/200907/msg00017.html
>
> The issues raised in these emails have been catalogued in the 
> spreadsheet prepared by Erik:
> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
> as well as other issues that have been raised in the public review period.
>
> I believe there are significant substantive issues that remain to be 
> addressed, in particular, in the hierarchical profile, in the area of 
> XML document resources, that were not visited within the scope of 
> changes to the hierarchical profile in 3.0.
>
> *****************************************************************
> This particular issue, CD-1 #11 appears to me to be a good starting 
> point to begin to address the overall issue of the handling of XML 
> resources in the hier/multiple profiles. I will repeat the text of the 
> issue here, and after that, comment on it, along with some starting 
> suggestions as to how to address it (actually, I have edited it 
> slightly for readability and inserted a couple clarifying notes that I 
> needed to understand a couple of points):
>
> *******************************************
> Issue CD-1 #11:
>
> Comment 2: Line 56: interoperability problem 
>
> “[XPath] expressions can be used to reference nodes in this document 
>  in a standard way, and can provide unique representations for a given 
>  node in the document.” ([3], S. 3). 
>
>  Forcing to use XPath expressions referring to exactly one node in the 
>  <ResourceContent> element limits the representation possibilities, 
>  which is a step in the right direction. 
>
>  But this still leaves some flexibility for no real reason and might 
>  therefore cause interoperability problems. Example:
>
>  A resource-id attribute value in an individual decision request might be:
>
>     /Request[1]/Resource[1]/ResourceContent[1] 
>      /wfs:FeatureCollection[1]/gml:featureMember[1]/Building[1]
>
>  A rule e.g. allowing access to building nodes will have a predicate like 
>  the following:
>
>     regexp-string-match( 
> 	resource-id, 
> 	/Request[1]/Resource[1]/ResourceContent[1]
> 	 /wfs:FeatureCollection\[\d+\]
> 	 /gml:featureMember\[\d+\]
> 	 /Building\[\d+\]$)
>
>  By using such a predicate all decision requests referring to “Building” 
>  nodes will match and the rule will get evaluated. 
>
> 	(note: $ (dollar) Matches at the end of the string the 
> 	 regex pattern is applied to. 
> 	 Matches a position rather than a character. 
> 	 Most regex flavors have an option to make the dollar match 
> 	 before line breaks (i.e. at the end of a line in a file) 
> 	 as well. 
> 	 Also matches before the very last line break if the string 
> 	 ends with a line break. 
> 	   http://www.regular-expressions.info/reference.html )
>
>  In this example we used the abbreviated XPath syntax to refer to exactly 
>  one node. 
>
>  In case the Context Handler uses unabbreviated XPath syntax when deriving 
>  the individual decision requests from a global decision request the rule 
>  won’t match any more. 
>
> 	(note: abbreviated syntax in xpath spec:
> 	  http://www.w3.org/TR/xpath#path-abbrev
> 	 refers to prefixes like child:: etc.
>
> 	   "The most important abbreviation is that child:: 
> 	    can be omitted from a location step. In effect, 
> 	    child is the default axis. 
>
> 	    For example, a location path div/para is short 
> 	    for child::div/child::para.")
>
>  Conclusion: 
>
>   In order to get a unique representation for a node in the document it 
>   should be specified more precisely which syntax the XPath values of 
>   the resource-id attribute have to conform. 
>
>   We recommend to use a syntax as shown in the example (i.e. 
>
> 	/elementNodeName[integer]/../elementNodeName [integer] 
>
>   in case of element nodes and 
>
> 	/elementNodeName[integer]/../@attributeNodeName 
>
>   in case of attribute nodes. 
>
>  Additionally the question is whether the XPath expressions should 
>   always refer to the <xacml-context:Request> element as its context 
>   node or to the content element that is additionally identified 
>   through the category attribute? 
>
>  If you choose option one 
>
>     (i.e. the <Request> element is the context node), 
>
>   then XPath expressions will always start with 
>
>     /Request... 
>
>   (c.p. e.g. line 4907 in the core XACML 2.0 specification).
>
>  Remark: Note that it is not possible to use the XPath node matching 
>   function in order to make the exact form of the xpath expression 
>   irrelevant. 
>
>   The reason is that XPath node match functions imply certain limitations 
>   in our use case like:
>
>     • only predicates supported by XPath can be used to define content 
>       dependant authorizations à limited expressiveness
>
>     • no pointers to XACML decision request data inside an XPath predicate
>       (e.g. permit access if /bulding[owner = subject-id]) 
>       àlimited expressiveness
>
>     • filtering is not possible
>
> 	– the XACML decision response refers to the Web Service request 
> 	  or response as a whole
>
>   
> *******************************************
>
> The above looked ok when I inserted it, hopefully the editors along 
> the way don't mess it up too much. :)
>
> In any event, here are a couple of initial comments on the issue:
>
>    1. From the above expression, where
>       regexp-string-match(resource-id, "xpath string") is given as a
>       sample predicate for a Rule, and the follow-up comments on
>       "recommended syntax" for the xpath expressions, it is clear to
>       me at least, that one significant paradigm for XML resource
>       processing is to treat the xpath expression as a string, and as
>       an instance of an explicit identity name for a resource.
>       Similarly, regular expressions can be applied to this syntax for
>       the purpose of "scoping" tests to determine whether the Rule is
>       applicable.
>       IMO, this comes very close to putting the xpath string on the
>       level of a URI, and in fact, w escape sequences, I think we can
>       probably consider it an instance of the URI strings described in
>       section 2.2 of the hierarchical profile. Therefore, part of my
>       suggested change to the profile is to consider this paradigm in
>       the context of representation of the identities associated with
>       XML document resources.
>    2. This also raises an issue of processing of XML document
>       resources. In particular, is it necessary to always send the
>       whole XML document in each of the detailed requests, which
>       probably entails significant xml processing overhead, in
>       general, even considering optimizations for non-xml processing
>       of the data. In some ways, I see this as equivalent to sending a
>       complete directory listing of all the files in a file system
>       with each request for access to a file. While, that is ok in
>       some situations (maybe?), I expect people will look to
>       alternatives, esp.in the area of send just the file name that is
>       being requested and setting policies to parse the file name
>       against scope file name expressions of the type described in the
>       multiple resource profile.
>       The bottom line here is that I agree that there should be
>       standard xpath expression syntaxes specified as a best practice
>       for specific installations. Then given the standard syntax,
>       policies can be specified treating xpath expressions like file
>       names and determining if the xpath expression identifying the
>       requested resource, falls within the scope of an xpath
>       expression in the policy describing the nodes that particular
>       expression is targeting.
>       The recommendation is to give an example of this type of scoping
>       in section 2.1 and refer to section 2.2 as the broader context
>       within which the paradigm may be viewed as URI scoping expressions.
>
> Please regard the above as an initial proposal which describes roughly 
> the type of changes that I think can be put in the profile to address 
> the issue that has been raised.
>
> Thanks,
> Rich
>
>
>
> Erik Rissanen wrote:
>> The issue number refers to the XLS-sheet found in this email:
>> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
>>
>> The commenter says that the way an xpath expression identifying a 
>> resource is not defined strictly enough that the expression can be 
>> used in string match functions.
>>
>> However, the constructed xpath expression is intended to be used with 
>> xpath match functions, where the exact, characted by character, form 
>> does not matter.
>>
>> I propose that we make no change.
>>
>> Best regards,
>> Erik
>>
>> ---------------------------------------------------------------------
>> 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