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