Re: AW: [xacml] RE: XACML's limitations in the access control forXML documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpathdefinition

[Erik Rissanen <erik@axiomatics.com>]

Hi All,

One complication in this whole discussion is that it mixes up several 
different use cases. There is a difference between doing access control 
on a resource which is described by an XML document and doing access 
control to sections of an XML document itself.

Let me try to illustrate:

Use case 1, XML is used to describe the attributes of a single resource:

<Subject>Alice</Subject>
<Resource>
<Content>
<book>
<title>xxx</title>
<author>Bob</author>
<id>100</id>
<price>30</price>
<book>
<Content>
<Resource>

In this case the question is "Is Alice allowed to get access to this 
book, whose metadata is described by the given XML content?". (For 
instance, this could be for access control in a digital library.) Note 
that the question is _not_ "Is Alice allowed to see the title of this 
book?" That is a different use case, which I discuss below.

This is something which XACML handles well as it is.

Use case 2, XML is used to describe the attributes of a multiple resources:

This is like a series of requests as in use case 1, and it should be 
encoded as multiple <Resource> elements. Like this:

<Subject>Alice</Subject>
<Resource>
<Content>
<book>
<title>xxx</title>
<author>Bob</author>
<id>100</id>
<price>30</price>
<book>
<Content>
<Resource>
<Resource>
<Content>
<book>
<title>yyy</title>
<author>Alice</author>
<id>101</id>
<price>300</price>
<book>
<Content>
<Resource>

If you encode it like this, XACML works well and there is no need for an 
offset. It would be misuse of XACML to encode it as a single Content 
element and use xpath to select the two books.

Use case 3, XACML is used to perform access control on an XML document 
itself:

<Subject>Alice</Subject>
<Resource>
resource-id=MedicalRecord/Treatment[1]/node()
<Content>
<MedicalRecord>
<Patient>
<SocSecNo>....</SocSecNo>
....
</Patient>
<Treatment>
<Infection>HIV</Infection>
<Medication>...<Medication>
</Treatment>
<Treatment>
<Infection>HepC</Infection>
<Medication>...<Medication>
</Treatment>
<MedicalRecord>
<Content>
<Resource>

In this case the request says "Is Alice allowed to see the data about 
the first treatment in the list of treatments this patient has received?".

This is fundamentally different than the above case, and it isn't quite 
what XACML was designed for in the first place. "Normal" XACML is based 
on that the request defines the attributes of a single resource. The 
attributes can be described in the form of URI identified attributes, or 
as free form XML in the <Content> element.

Instead, what we see in use case 3 that the request contains multiple 
resources. But there is a fundamental difference to how the multiple 
<Attributes>/<Resource> elements multiple resource profile works. With 
multiple <Attributes> elements, a "pre-processor" to the PDP will 
transform the request into individual requests which contain attributes 
of only a single resource. This means that the policy which works on 
these types of requests needs to be no different from a policy which 
works on an individual request. Any attribute selectors simply refer to 
metadata about this individual resource.

But in use case 3, the pre-processor will not make a clean split of the 
resources. All the resources follow into all the individual requests, so 
a policy which is used to control access to pieces of an XML document 
will have a different form and needs different capabilities. XACML 
currently does not have capabilities to handle this use case well. XACML 
works for simple requirements like "You can see all "Treatment 
elements", but not for more complex ones like "You can see those 
treatment elements which do not contain the <ConsentRequired> element" 
which require resolving relations between sections of the XML document.

Perhaps we should split up the multiple resource profile into two 
different profiles:

1. "Multiple Resource Profile of XACML 3.0". This would contain the 
multiple <Attributes> elements based functionality as well as the 
"scope" based functionality on hierarchies defined with URI-attributes. 
Note that these forms of multiple request transform cleanly into 
individual XACML requests with single resource.

2. A new "Access control on XML documents Profile of XACML 3.0". This 
profile would define how we handle use case 3, and here we probably need 
new capabilities, like the offset, or something similar. We also need to 
figure out how these kind of policies interact with normal policies. I 
am worried that evaluation a "normal" policy on an XML document request 
could lead to confusing results, so we need to work out the security 
issues of a PDP which contains mixed types of policies. (I am not saying 
that I know there is a problem, I just want that we make sure that there 
isn't one.)

I also suspect that to properly do XML access control on XML documents, 
then other features besides the offset could be needed, so we should 
read up on the research in this issue.

If this sounds good, we could do profile 1 in the first batch of 3.0 
documents, and do 2 for the next batch, so we can do a proper work on 
it, say within a year or so.

Best regards,
Erik




Jan Herrmann wrote:
> HI Paul,
> see comments inline and the edited attached files.
> Best Regards
> Jan
>
> ________________________________________
> Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] 
> Gesendet: Donnerstag, 24. September 2009 21:01
> An: Jan Herrmann; Erik Rissanen; Rich.Levinson
> Cc: xacml@lists.oasis-open.org
> Betreff: [xacml] RE: XACML's limitations in the access control for XML
> documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpath
> definition
>
>   
>> 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.)
>>     
>
> Yes, a book-request implies a book-response. In our use case we have xml
> based Web Service requests and response. Thus you have two options when to
> enforce your access rights - either on the web service request or on the
> response. Lets follow the later case (i.e post-processing access control) in
> the following.
>
>  
>   
>> 2. Do we agree that current XACML 3.0 drafts (core, hier, multi) do not
>> provide features to achieve (1)?
>>     
>
> Depending on how much expressiveness you need, some large parts can already
> be done with the specs. In order to enhance expressiveness little extensions
> are needed.
>  
>   
>>   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.
>>     
>
> I attached a doc showing another example in another geospatial scenario
> (c.p. Apendix A). Note that the approach 2 was just for explanation purposes
> (demonstrating the probs) and is not what I recommend to do.
>  
>   
>> 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
>>     
>
> Following the multiple and hierarchical resource profile, there is a first
> global decision request with an resource-id and scope pair. Both together
> describe a set of nodes.
>
> The resource-id value you proposed can only be a value in a GLOBAL decision
> request. In an individual decision request (that is derived automatically by
> the PDP following the guidelines in the mult. & hier. resource profile) the
> resource-id value must refer to exactly one node. This must be one node that
> was originally specified by the resource-id and scope value of the global
> decision request. Thus example values of the individual resource-id values
> in the different decision requests are e.g.:
> derived decision request one:
> resource-id=ns1:objects[1]/ns1:book[1]
> derived decision request two:
> resource-id=ns1:objects[1]/ns1:book[2]
> ...
>
> if you go down the book trees depends on the chosen scope value. e.g. in
> case of dependants you would do that.
>
>   
>>     Response: resource-id=ns1:objects/ns1:book[1], ns1:objects/ns1:book[2]
>>     
>
> if your decision requests asks for multiple responses (one for each node)
> than you get back n individual decision responses. The resource-id values
> will therefore also be:
> resource-id in decision response 1:	resource-id =ns1:objects/ns1:book[1]
> resource-id in decision response 2:	resource-id =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.
>>     
>
> The question here is if it is sufficient to say that the resource-id value
> of an individual request has to match exactly one node (as the spec
> currently says) or whether it makes sense to specify a certain form.
> Depending on how you write the Target Match part a certain form may be
> required.
>
> If you match like this you are free to define the exact syntax of your
> resource-id values.
> In the Rule Target:
> xpath-node-equal(resource-id, /objects/book)
>
> If you match like this a certain form must be defined in order to ensure
> interoperability.
> In the Rule Target:
> reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\])
>
>
> Note that these are two equivalent options and whether option 1 is better
> than option 2 still needs to be discussed. Performance might be an issue in
> case 1 and favour option 2. On the other side option 2 has to deal
> explicitly with the namespace prefix prob.
>
> Attached I edited your examples in the way how I would do it. Note that I
> was in a rush so I hope I got them mostly right.
>
> Best regards 
> Jan
>
>   
>>  
>> 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>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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