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

["Rich.Levinson" <rich.levinson@oracle.com>]

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:

4AAA4C83.1090703@axiomatics.com" type="cite">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