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

Hi Prateek,

 

just two little comments:

First, I wouldn't say that fine-grained access control
for web services is an extremely specialized use case.

Second, yes your rules are dependant on the explicit structure of the
web service request, response and business data. I can’t think of a feasible solution of using abstract identifiers
- such as URIs or URNs - so that a layer of abstraction is provided.

In short I see the following problems:

XACML Attributes (which is what I believe is what you mean by URIs or
URNs)...

·        
destroy the hierarchical structure
and the semantical relationships in the OWS request or response data

·        
imply more generalized i.e.
coarse-grained  atomic information entities. XACML Attributes are only useful
if the information is atomic without structural relation

·        
lots of URNs for attribute-names
& -values have to be defined for unique identification 

(e.g. action-id = { getMap, getFeature, transaction, insert, update, delete...})

My Conclusion for the Attribute/AttributeDesignator approach in the WS
or XML use case: 

·        
not powerful enough as arbitrary
WS requests and responses (i.e. XML data) can not be easily, completely
transformed into appropriate XACML Attributes without reducing the possible
authorization semantics

·        
XACML Attributes
are not suitable for the representation of WS 

    specific information in access control
decision requests. 

 

And as you said this behaviour is and should be described in a profile –
I’d recommend to rewrite the multiple and the hierarchical resource
profile . The core spec just needs to define the necessary background. 

 

Best regards 

Jan

 

 

> -----Ursprüngliche Nachricht-----

> Von: Prateek Mishra [mailto:]

> Gesendet: Donnerstag, 24. September 2009 15:34

> An: Jan Herrmann

> Cc: ; 'Erik Rissanen';
'Rich.Levinson';

> 

> Betreff: Re: [xacml] XACML's limitations in the access control for
XML

> documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
xpath

> definition

> 

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

> > *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"
<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

> >

> >