Hi Paul,
I will defer to Jan on the particulars of the GeoXACML use case.
I hadn't really looked at the XML document aspect of the hierarchical
profile until this issue came up, however, after mulling it over a bit
I noticed a couple of aspects to it that I consider somewhat
constraining from a general perspective. I will briefly itemize what I
think are the main points to consider wrt alternative approaches:
- XPath node matching requires the presence of the actual document
to parse and collect nodes and determine if the collected nodes are
subject to the applicable policy. In general, the hierarchical profile
considers these nodes to be actual resources, and as a result, the
fundamental XPath paradigm from an access control perspective requires
accessing the particular resource to determine if access to the
resource is allowed.
By comparison, the direct node addressing approach that I have
suggested, taken by generalizing the example Jan gave in the issue,
does not require access to the nodes, because it relies on path scoping
and matching much like scoping and matching is done with typical file
access policies, which generally control access without having to
actually access the target file.
- From a performance perspective, it appears to me that very large
XML documents that have catalogs of information will generally require
some significant overhead when collecting nodes for applicability
tests.
With the direct node naming approach, this is again not a problem,
because the decisions can be made without processing the file.
- For more complex policies, where XPath expressions can add a lot
of richness, in general, there is no guarantee that all the relevant
nodes to collect in order to make a decision will even be in the target
document, in which case, one will need to switch paradigms in order to
collect any nodes outside the scope of the particular XPath domain.
With the direct node naming approach, one may have more awkward
techniques required to get specific additional nodes within the target
document, but the whole policy expression paradigm can be consistent as
both xml and non-xml resources can be represented the same way using
URIs.
Again, this is being proposed as an alternative approach, for
situations where some of the above tradeoffs may make the direct
node-naming paradigm more desirable than the XPath paradigm.
I am not sure if Jan necessarily "needs" this approach to address the
particular GeoXACML concerns, but I am proposing it as a possible
solution for that use case, plus having analyzed and recognizing the
above comparisons between XPath node matching and explicit node-naming
for string matching, I think it may prove to be useful in general.
Thanks,
Rich
Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF09603CB4F2A@txamashur004.ent.textron.com"
type="cite">
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
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:
4AB3D421.50103@oracle.com" type="cite">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
|