Hi Jan,
And welcome to the TC. :-)
See inline for my response.
Jan Herrmann wrote:
> First of all it is important to note that the problem you described has
> nothing to do with the discussion whether to do string matching on xpath
> expressions or not.
>
It has everything to do with xpath vs string matching. See below.
>
>
> Your example would only occur if your PEP or PDP can add two completely
> different xml resources to the decision request which are (at least in
> parts) syntactically very similar (but not semantically – and thus the ac
> semantics should be different). E.g.
>
>
>
> resource one:
>
> <foo:Book>
>
> where foo is bound to xmlns:foo="example.com/nsA"
>
>
>
> and the second resource looks like:
>
> <foo:Book>
>
> where foo is bound to xmlns:foo="example.com/nsB"
>
>
>
> Having a rule pointing to /foo:Book through an Attribute selector or an
> XPATH Matching function will cause the rule to get applied in both cases.
> Here it becomes clear that the problem is independent of the discussion
> whether string matching on xpath expressions should be supported or not.
>
No, it won't apply in the xpath case. Let's say we have the following
attribute selector (XACML 3.0 syntax):
<AttributeSelector
xmlns:foo="http://example.com/nsA"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
RequestContextPath="foo:Book"
MustBePresent="true"
DataType="http://www.w3.org/2001/XMLSchema#string"/>
then it will match the following resource content:
<Content xmlns:foo="http://example.com/nsA">
<foo:Book>.....
</foo:Book>
</Content>
but it will not match the following
<Content xmlns:foo="http://example.com/nsB">
<foo:Book>.....
</foo:Book>
</Content>
This is because xpath does take the namespaces into account. String
functions do not. Relying in a particular form for xpath expressions,
namespace prefixes, etc, and assuming that requests never could collide
is a huge security risk and otherwise problematic.
Best regards,
Erik
