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

 

 

 

 

Von: Tyson, Paul H [mailto:] 

Gesendet: Montag, 21. September
2009 16:24

An: Rich.Levinson; Erik Rissanen;
Jan Herrmann

Cc: 

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

Sent: Sunday, September 20, 2009
18:41

To: Erik Rissanen; Jan Herrmann

Cc: 

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"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 

RequestContextPath="foo:Book" 

MustBePresent="true" 

DataType="http://www.w3.org/2001/XMLSchema#string"/>

then it will match the following resource content: 

<Content xmlns:foo="http://example.com/nsA">

<foo:Book>..... 

</foo:Book> 

</Content> 

but it will not match the following 

<Content xmlns:foo="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