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
