Hi Paul,
Yes, this summarizes very well issue #16, though I cannot find anything
about the offset in the syntax of your sample policy.
And I agree that the use case is valid and I have seen it in the real world.
I am not entirely sure yet that the offset is the best way to solve it
(maybe it is, but I would like to think more about it).
Best regards,
Erik
Tyson, Paul H wrote:
> 1. Given this use case, are we agreed that we want to get
> book-response when we send book-request? (Please correct any content
> errors in these documents--I have not been using Content and xpath
> features of XACML.)
> 2. Do we agree that current XACML 3.0 drafts (core, hier, multi) do
> not provide features to achieve (1)? If anyone has such a solution,
> please post. Jan's "Approach 2" uses xpath predicate, based on
> simplicity of this example, but that is not a general solution.
> 3. book-policy.xml illustrates the xpath "offset" feature that has
> been discussed [1] as a solution. (Again, please correct any errors.)
> 4. Where do the specs define the return value for an xpathExpression
> resource-id? In my example, I have:
> Request: resource-id=ns1:objects/ns1:book
> Response: resource-id=ns1:objects/ns1:book[1], ns1:objects/ns1:book[2]
> Many other trivial, but equivalent, variations could have been
> returned. But I only guessed at these from an example Erik gave, not
> from anything I read in the specs. I would expect to find it in multi
> section 2.2.
> Regards,
> --Paul
> [1] http://lists.oasis-open.org/archives/xacml/200909/msg00023.html
>
> ------------------------------------------------------------------------
> *From:* Jan Herrmann [mailto:]
> *Sent:* Thursday, September 24, 2009 07:00
> *To:* Tyson, Paul H; 'Erik Rissanen'; 'Rich.Levinson'
> *Cc:*
> *Subject:* XACML's limitations in the access control for XML
> documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
> xpath definition
>
> 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>
>
