Hi Jan, et al,
I have had a busy week and not been able to respond until now, however,
looking over all the subsequent emails to the one to which this is a
response (
http://lists.oasis-open.org/archives/xacml/200909/msg00081.html
), it appears to me that there are still unresolved issues, and from my
perspective, there are some assertions made, with which I disagree,
about AttributeDesignators, which I thought my suggested URI scheme
would address, but apparently it either needs further explanation or I
am missing something that I have not yet understood. In any event I
would very much like to determine whether these assertions are true or
false in order that the TC be of a single mind when comparing the
capabilities of AttributeSelectors and AttributeDesignators.
The assertion with which I disagree is that the
AttributeDesignators cannot do what the AttributeSelectors can do
because the AttributeDesignators lose the hierarchical structure. My
response is that if you don't throw away the hierarchical structure
when creating your AttributeDesignators then this perceived problem
does not exist.
If I am wrong about this, I will accept that, however, I do not believe
that my approach to the AttributeDesignators has been considered on its
merits yet, and I will try to be totally explicit in this email, and I
will show how I think Jan's proposed solution can be completely done
using only AttributeDesignators and regexp string matching.
Having been thru some lengthy discussions earlier this year on the
hierarchical profile, I became quite sensitive to the node naming
issue, and one of the results of those earlier discussions was that if
hierarchical URIs are used to name nodes, that these names contain
within them the navigation necessary to locate the node, so that using
these names outside of an XML document does not lose the structural
relationships.
Using James Clark's universal name syntax ("{namespace}elementname"
http://www.jclark.com/xml/xmlns.htm) combined with a transform to
replace the xml document with a list of name/value pairs (there are
several XML to JSON xslt transformers available free, which I expect
could readily be adapted to produce name/value pairs in the format
below), where each element and attribute is identfied by its full path
expressed as universal element names. For example, assuming the
document you gave as an example had a namespace = "foo":
<objects xmlns:="foo">
<book>
<title>xxx</title>
<author>Bob</author>
<id>100</id>
<price>30</price>
<book-content>…..</book-content >
<book>
<book>
<title>yyy</title>
<author>Alice</author>
<id>200</id>
<price>80</price>
<book-content >...</book-content >
<book>
</objects>
The above document would first be transformed to the following set of
name value pairs (ignoring whitespace):
/{foo}objects = ""
/{foo}objects/{foo}book[1] = ""
/{foo}objects/{foo}book[1]/{foo}title = "xxx"
/{foo}objects/{foo}book[1]/{foo}author = "Bob"
/{foo}objects/{foo}book[1]/{foo}id = "100"
/{foo}objects/{foo}book[1]/{foo}price = "30"
/{foo}objects/{foo}book[1]/{foo}content = "..."
/{foo}objects/{foo}book[2] = ""
/{foo}objects/{foo}book[2]/{foo}title = "yyy"
/{foo}objects/{foo}book[2]/{foo}author = "Alice"
/{foo}objects/{foo}book[2]/{foo}id = "200"
/{foo}objects/{foo}book[2]/{foo}price = "80"
/{foo}objects/{foo}book[2]/{foo}content = "..."
The next step is to define resources, which for this use case would be
done based on multiple resource profile, where we would have 2
resources, using Erik's shorthand:
<Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>
<Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>
The next step is to create xacml attributes for these resources using
the full universal names as AttributeIds (again w some shorthand),
resulting in the following 2 requests:
(Note: since AttributeId requires anyURI datatype, the following
percent-encoding must be applied to the AttributeId values:
{ -> %7B
} -> %7D
[ -> %5B
] -> %5D )
<Request>
<Subject>subject-id="Bob"</Subject>
<Resource>
<Attribute>AttributeId="resource-id"
value="/{foo}objects/{foo}book[1]"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dtitle"
value = "xxx"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dauthor"
value = "Bob"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Did"
value = "100"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dprice"
value = "30"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dcontent"
value = "..."</Attribute>
</Resource>
</Request>
<Request>
<Subject>subject-id="Bob"</Subject>
<Resource>
<Attribute>AttributeId="resource-id"
value="/{foo}objects/{foo}book[2]"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dtitle"
value = "yyy"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dauthor"
value = "Alice"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Did"
value = "200"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dprice"
value = "80"</Attribute>
<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dcontent"
value = "..."</Attribute>
</Resource>
</Request>
All the above processing to create the requests is done in the
ContextHandler, then the requests are submitted one at a time to the
PDP.
Now the rule that gets applied to each of these requests is the
following:
<Rule effect=Deny>
Target:
reg-exp-string-match(resource-id, /{foo}objects/{foo}book\[\d+\]
Condition:
AttributeDesignator(AttributeId =
function:string-concatenate(resource-id, /%7Bfoo%7Dprice) > 50 and
AttributeDesignator(AttributeId =
function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =
AttributeDesignator(subject-id)
</Rule>
Unless I am mistaken, all the logic and structure is retained and it
has been done purely w AttributeDesignators and regexp.
Assuming the above is correct, then the points I made about the
advantages over XPath (for an enterprise looking to use only URIs to
identify attributes):
The XML document does not need to be passed in with the request.
There is no node collection, only string operations.
For very large XML documents, say a catalog of 10,000 books, each
book is processed individually independent of the other books, as
compared to the XPath case, where one might expect the whole document
has to get parsed for each of the 10,000 individual requests.
There is no paradigm shifting, or what I believe was referred to
in the discussion as "shifting semantics between XPath and XACML in
terms of representing the policies.
Again, assuming the above is correct, I am not assuming this will be
desirable for everyone, however there may very well be organizations
for whom the advantages of this approach are decisive.
A couple other points are that
the "unsightliness" of the AttributeIds and the
AttributeDesignators can be "covered" up by policy tools that
facilitate defining policies based on XML Schemas, and can keep all the
encoding details transparent to the policy designers.
the issue about basing policies on the structure of XML documents
is a legitimate concern, however, if structure of documents change,
then a legitimate case could probably made that the namespace
associated with that structure should also change, which would mean the
policy tools would need to be able to facilitate upgrading of policies
to new namespaces based on new revs of the schemas.
Comments and suggestions welcome.
Thanks,
Rich
Jan Herrmann wrote:
Hi Paul, all
in
the following I try to
explain some limitations of the current version of the multiple and
hierarchical resource profile and the core-spec in the xml-resource use
case. Then
through an example I will show how the proposed extensions could
enhance the capabilities
and expressiveness significantly.
Baseline:
-
you are trying to
control access to xml resources on a fine-grained level
-
contend dependant rules
should be supported. i.e. it must be possible to express access rights
for a
node that are dependant on the value of other nodes
-
filtering should be
supported. I.e. in case access to one (or some) node(s) in the xml
resource is
denied, it should be possible to filter out these nodes and return the
accessible part of the xml-resource to the user
Example
Scenario:
To
simplify the
discussion assume the following situation:
You
have xml docs looking
like this one:
<objects>
<book>
<title>xxx</title>
<author>Bob</author>
<id>100</id>
<price>30</price>
<book-content>…..</book-content
>
<book>
<book>
<title>yyy</title>
<author>Alice</author>
<id>200</id>
<price>80</price>
<book-content
>…..</book-content >
<book>
</objects>
This
resource is included
in a global decision request which looks like this:
<request>
subject-id=Bob
<content>…the
xml resource </content>
</request>
Further
assume you try to
define a rule, that denies access to book nodes, if the book’s price is
higher than 50$ and the author OF THIS BOOK is the requesting subject.
A
first try to define the
needed rule could look like this:
Approach
1:
<Rule
effect=Deny>
…Any-Of(less-than,
50, AttributeSelector(/objects/book/price/text()) ) AND
Any-Of(string-equals,
string-one-and-only(AttributeDesignator(subject-id)),
AttributeSelector(/objects/book/author/text()) )
</Rule>
Unfortunately
this rule
doesn’t implement the intended behaviour.
Prob
1: filtering is not
possible
The
XACML decision request
& response refers to the XML resource as a whole. What you actually
need to
allow filtering are access decision request and responses for each
individual
node.
Prob
2: The use of two and-ed
Any-Of expressions destroys the
semantical
relationships between the nodes
If
e.g. Bob is the
requesting subject, than the rule will match and deny access although
Bob
should be allowed to access the first and second book element.
Note
that this problem
could be solved, if you would allow the following type of xpath
expression in
the AttributeSelector:
Approach
2:
integer-greater-than
(integer-one-and-only(AttributeSelector(count(/objects/book[price/text()>50
AND author/text() = AttributeDesignator(subject-id)])), 0).
This
is not possible as XACML
constructs like the AttributeDesignator can’t be used inside the XPATH
predicate.
Another
approach that is
XPath conformant could therefore be:
Approach
3:
<Rule
effect=Deny>
…Any-Of(string-equals,
string-one-and-only(AttributeDesignator(subject-id)),
AttributeSelector(/objects/book[
price/text() > 50]/author/text()) )
</Rule>
This
rule should implement
the intended access semantics but still has its limitations:
1.
The problem was solved
through a mix of XACML constructs and XPath predicates. To overcome the
limitations parts of the XACML constructs were shifted into the XPath
predicate.
Note that this worked in the example, as a less-than or higher-than
function is
allowed in XPath predicates. Unfortunately this means that XACML’s
functions are not eXtensible below the functions supported by XPath.
E.g.
in the OGC GeoXACML
use case we have added functions like within, touches, disjoint and so
on. As
these functions are not supported by XPath they can only be used in the
extened
form of XACML and this introduces strong limitations in the
expressiveness.
2.
Assume you want to change
the intended rule semantics to:
deny
access to a book
node, if the book’s price is higher than an XACML Attribute A and the
author
OF THIS BOOK is the requesting subject
This
will prevent you
from shifting the semantics into the XPath predicate and thus will
cause
limited expressiveness.
From
my understanding
using the xpath-match functions doesn’t help solving the problems
mentioned above.
Filtering
will still not
be possible and the problem that pointers
to XACML decision request data are not allowed inside an
XPath predicate and the problem that only predicates supported by XPath
can be
used still
apply.
The
good news is that
with very little changes to the profiles the problems above can be
solved.
A
solution could look like
this:
1.
A PDP receives a global
decision request with
resource-id=/objects
scope=descendant
<content>… the xml resource </content>
The resource-id
and scope Attribute specifies a set of nodes that are the individual
resources
for which the access rights have to be checked.
2.
Based on this global
decision request the PDP generates individual decision requests. – one
for
each individual node.
Thus the
PDP generates the following decision requests:
<request>
subject-id=Bob
resource-id=/objects[1]
<content>…the
xml resource </content>
</request>
<request>
subject-id=Bob
resource-id=/objects[1]/book[1]
<content>…the
xml resource </content>
</request>
<request>
subject-id=Bob
resource-id=/objects[1]/book[1]/title[1]
<content>…the
xml resource </content>
</request>
<request>
subject-id=Bob
resource-id=/objects[1]/book[1]/author[1]
<content>…the
xml resource </content>
</request>
<request>
subject-id=Bob
resource-id=/objects[1]/book[1]/price[1]
<content>…the
xml resource </content>
</request>
…
<request>
subject-id=Bob
resource-id=/objects[1]/book[2]
<content>…the
xml resource
</request>
…
3.
Having these decision
requests allows you to define very powerful rule semantics and
filtering is
supported too.
e.g. the
rule in the example above would look like this
<Rule
effect=Deny>
Target:
reg-exp-string-match(resource-id,
/objects\[\d+\]/book\[\d+\]
Condition:
AttributeSelector(concat(resource-id,
/price/text()) > 50 and
AttributeSelector(concat(resource-id,
/author/text()) = AttributeDesignator(subject-id)
</Rule>
Note
that all the
problems mentioned above are solved.
Filtering
is possible as
resource-id always refers to exactly one node in the xml resource and
thus we
get individual access decisions for each node in the xml resource. As
resource-id is included in the decision response the PEP can (e.g.
through a
simple xslt) filter out the nodes for which the decision was deny.
Further
the problem of
defining content dependant rights without reducing the possible
authorization
semantics is solved, thanks to an AttributeSelector that uses a
concatenation
of the resource-id attribute value and an arbitrary offset as its
RequestContextPath
value.
Note
that the
explanations above are simplified and try to focus the core aspects of
the idea
only. I hope that I could nevertheless make clear where the limitations
are and
how they could be solved.
Let
me know if you have
problems understanding the ideas and I will try to explain in more
detail. Further,
more detailed information can be found in the comments I submitted
during the
public review period.
Best
regards
Jan
Von:
Tyson, Paul H [mailto:]
Gesendet: Montag, 21.
September
2009 16:24
An: Rich.Levinson;
Erik Rissanen;
Jan Herrmann
Cc:
Betreff: RE: AW:
[xacml] CD-1
issue #11: strictness of xpath definition
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
