Re: [xacml] XACML's limitations in the access control for XML documentsuse case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath definition

[Prateek Mishra <prateek.mishra@oracle.com>]

IMHO, this use-case is an extremely specialized one, and one that rarely 
arises in commercial practice.

I also have some fundamental questions about how such an approach scales 
- suppose there is some small change in the schema of tthe document, 
then the entire policy has to be redone. Tying in access control policy 
to the explicit structure of business data - whether a file system or a 
database table or an XML document is a bad idea. The use of abstract 
identifiers - such as URIs or URNs - so that a layer of abstraction is 
preserved is the standard approach in the industry.

At a minimum, I would suggest that this be solved via a separate profile 
or extension to the core XACML system.

- prateek
>
> 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:PTyson@bellhelicopter.textron.com]
> *Gesendet:* Montag, 21. September 2009 16:24
> *An:* Rich.Levinson; Erik Rissanen; Jan Herrmann
> *Cc:* xacml@lists.oasis-open.org
> *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:rich.levinson@oracle.com]
>     *Sent:* Sunday, September 20, 2009 18:41
>     *To:* Erik Rissanen; Jan Herrmann
>     *Cc:* xacml@lists.oasis-open.org
>     *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"; <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";
>     <http://www.w3.org/2001/XMLSchema#string>/>
>
>     then it will match the following resource content:
>
>     <Content xmlns:foo="http://example.com/nsA"; <http://example.com/nsA>>
>     <foo:Book>.....
>     </foo:Book>
>     </Content>
>
>     but it will not match the following
>
>     <Content xmlns:foo="http://example.com/nsB"; <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
>
>