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

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

Hi Erik,

I understand your concern re: xpath, in particular, however, XML 
documents are well formed hierarchies and there is no reason why a 
standard naming scheme for the nodes that would incorporate the type of 
scoping used for filename and URL policies should not be established. In 
the absence of such a std, xpath expressions may be a reasonable place 
to start, esp. w a limited syntax such as that was proposed by Jan in 
the original issue.

    Thanks,
    Rich


Erik Rissanen wrote:
> 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
>
>