[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: XACML's limitations in the access control for XML documents usecase - AW: AW: [xacml] CD-1 issue #11: strictness of xpath definition
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:herrmanj@in.tum.de] > *Sent:* Thursday, September 24, 2009 07:00 > *To:* Tyson, Paul H; 'Erik Rissanen'; 'Rich.Levinson' > *Cc:* xacml@lists.oasis-open.org > *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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]