OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Erik and Jan,

When I suggested starting w xpath expressions as a naming scheme, I had assumed we would properly incorporate namespaces. My limited (although not zero) understanding of XPath is that it is built around a normative data model:
http://www.w3.org/TR/xpath-datamodel/

I have not read this data model in any significant depth, but I do know that it is an explicit hierarchical representation of an XML document and that each element and attribute node can most likely be explicitly and uniquely addressed by a string of QNames (combo of resolved namespace prefix plus the local tag name) in the form:
/root-qname/qname/qname/...
where, in our case, the root-qname would probably be the top element of the doc.

I did come across a notation called the "Clark notation" where qnames can be written as:
{namespace URI}local-tag-name
So, if we had an xpath segment such as:

.../foo:Title[1]/bar:Name[1]
where xmlns:foo="example.com/nsA" xmlns:bar="example.com/nsB"

Then the actual string used for the resource-id and in the regexp matches would be:
.../{example.com/nsA}Title[1]/{example.com/nsB}Name[1]

While this may seem awkward from a user-friendliness point of view, I expect policy design tools can be developed to significantly ease the pain.

I think the bottom line is that the purpose here (in the context of the XACML hierarchical profile) is that the xml document represents a hierarchy of resources, where each node in the xml document is a potential resource (presumably only element and attribute nodes, but, whatever). Since the xml document is a well-formed hierarchy, and that xpath is based on a normative data model where these nodes are identified by qnames, it is fairly obvious that each node (resource) is addressable by a sequence of these qnames with "/" used for navigation and "[n]" used to differentiate nodes w same name in document order.

I believe we can also represent these qnames within the URI scheme if we percent encode any of the special characters needed to lay out the full sequences. Of course there would be details not covered here, but to get to that level would probably require some consensus that we wanted to incorporate the idea.

Once we are past that awkwardness of the exact naming format, but I think it is an awkwardness implicit in xml documents, somewhat hidden by the format of xml documents, but necessarily incorporated to any xml processing tools, then I think we have an almost exact analogy to file system naming patterns and the commonly understood scoping relationships used in that context.

This is not to say to not use xpath at all (in fact, I suggest leaving all the xpath stuff as is), but there may be circumstances where xpath is not appropriate, and a scheme like this is natural and consistent w the rest of the resource representation in the hierarchical profile. Further, I don't think this is "new" functionality, but simply explaining how an xml document resource hierarchy can be used within the already existing hierarchical profile constructs, i.e. a "missing piece" of the xml document part of the profile.

My suggestion is that we add a comment to this effect in section 2.1 explaining a suggested "naming" process, then pointing the reader to section 2.2 to the URI scheme of which the xml document would simply be a special case.

Thanks,
Rich




Erik Rissanen wrote:
4AB339DA.1040204@axiomatics.com" type="cite">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


---------------------------------------------------------------------
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]