OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]