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
