I'd like to understand the original use case before commenting on
the proposed solution.
Can Jan or Rich provide a complete example (rule, request,
response) that demonstrates capabilities of the proposed feature, which
cannot be met with existing provisions of the specification?
Thanks,
--Paul
From: Rich.Levinson
[mailto:]
Sent: Sunday, September 20, 2009
18:41
To: Erik Rissanen; Jan Herrmann
Cc:
Subject: Re: AW: [xacml] CD-1 issue #11:
strictness of xpath definition
Hi again Erik and Jan,
I did some further thinking about the
issue, and decided leaving the "details" for later was insufficient. I have
therefore attached a proposed change to the hierarchical profile, which I
think may address the issue.
The basic idea is to be able to identify
any explicit element or attribute in an XML document in an unambiguous manner
with a string to which regular expressions may be applied. As such, namespace
prefixs must be included directly in this identifier, and since each namespace
itself is a URI, it needs non-URI character delimeters to avoid it interfering
with other parsing. RFC 2396 prescribes "percent encoding" for such mechanics
within URI and URI-references (where the "URI-reference" includes the fragment
portion).
In order to see what this might look like if we were to take
this approach, what I have done is added a new sub-section, 2.2.1, which
expands on section 2.2 to include a hierarchical fragment portion of a
"URI-reference", which I believe is consistent w RFC 2396. I also included a
ref in section 2.1 pointing to this as an "alternate
representation".
Comments and suggestions
welcome.
Thanks,
Rich
Rich.Levinson wrote:
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:
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
