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] Re: XACML's limitations in the access control for XMLdocuments use case - AW: AW: [xacml] CD-1 issue #11: strictness of xpathdefinition

Hi Erik, Paul, Jan,

There has been good discussion in the last 6 emails:

Reviewing them all has led me to step back a bit and try to see a larger scope thru which all the details might be systematically viewed. I will try to present the larger scope that has helped me view these issues and then try to address a couple of the issues within that context.

Starting with the Multiple Resource Profile, I see 4 basic "hierarchical use cases", which involve "hierarchical node identification", which I think can reduced to 2 "hierarchical use cases", which may then be viewed as applying to xml and non-xml resources.

The 4 use cases I see in the Multiple Profile are the following (Note: the top node of the hierarchies involved in these use cases is generally the node identified by the " 'resource-id' attribute in the original request context", a phrase that appears on lines 111,115,143, 145. I think the term "original resource-id" can be used to distinguish this resource-id from the generated individual resource-ids that appear in the individual requests. Also, the original resource-id is used, as one of the individual requests as well.):
  1. resource:scope="Immediate" covered by section 2.3. This use case is essentially a "single" resource request and is relatively uninteresting (in the context of the hierarchical node-naming discussion), except for the fact that the individual "resource-id" attribute may be considered to be essentially the same as the "original resource-id" attribute. Also, section 2.3 covers the multiple single request use case, which is essentially non-hierarchical in nature and simply a list of resources
  2. resource:scope="Children" covered by sections 2.1 and 2.2, and consists essentially of sending a set of individual requests, which are each identified by "resource-id", where the "parent" or "original resource-id" is one request and each child of this parent has a "generated resource-id" to identify it. Also, all these resource-id's may appear in the individual Result elements that are returned and thus represents a tangible entity that needs to be explicitly implemented, because it can actually appear as a specific return element as an identifier of the explicit resource to which the Result applies.
  3. resource:scope="Descendants" also covered by sections 2.1 and 2.2, and represents the node identified by the "original resource-id" plus all the element and attribute descendants of the original resource-id node. Therefore, this use case requires the generation of a tangible resource-id for every element and attribute in a hierarchical resource including and below the element identified by the original resource-id. Again, these may be tangible return values, and therefore need to have a specific syntax and literal representation.
  4. resource:scope="EntireHierarchy" covered by sections 3.1 and 3.2. This use case is essentially the same as resource:scope="Descendants" except only one Result element is generated, and is therefore relatively uninteresting from a "hierarchical naming perspective".
The point of the above is to call attention to the two primary use cases: resource:scope="Children" and resource:scope="Descendants" that involve the issue of naming of nodes in a hierarchy. In this context, I note the following characteristics that I think may be of general interest:
  • Because the resource:scope="Descendants" use case requires the ability to provide a tangible unique identifier to every node in an XML document, if the original resource-id refers to the top node of that document, there is an implicit requirement to have an explicit name for every element in the hierarchy.
  • There appears to be no explicit "need" to send the actual XML document along with the Request, because all that is explicitly required is the resource-id Attribute. The only need for the XML document would be to look at additional attributes that may be in that document, but those attributes are outside the scope of anything in the Multiple Profile itself.
    • Assuming the above point is acknowledged, it can also be pointed out that while there may be policies written that use additional attributes, there is no reason to think that any, or all of those attributes necessarily would be found in the XML document.
    • Therefore, if agreement exists on the above 2 points, one might also be able to say that there really is no reason to restrict the attributes for the policies to be attributes that can be accessed specifically by the XPath mechanism, and therefore no real "reason" to restrict the node identification to be an XPath syntax as opposed to any other syntax.
  • What these points are getting at is the notion that within the multiple and hierarchical resource profiles there is an explicit need to define an explicit syntax for identifying the nodes in a hierarchy, be it and xml document or a non-xml document, but there is not explicit need that this syntax should be explicitly XPath.
Given all the above I think it is also fair to say that XPath does not even provide a syntax for explicit node-naming, although one can specify a syntax for node naming using namespace prefixes in the path, however, the XML document which has the resolution of those namespace prefixes in xmlns attributes will need to accompany the request in order to resolve the resource-id to a tangible value that can be included in an IncludeInResult return attribute.

Granted that in a totally self-contained XPath environment, one might be able to exist without ever explicitly naming a node outside of the presence of the XML document itself, or the document schema, it appears to me, at least, that such a situation kind of "bakes in" one specific technology that will be required to be used to identify these resources. This seems to me to be ok for specific implementations, but it also appears to me to be at odds with the spirit of the core XACML spec which states (lines 2659-2664):
"5.42 Element <Request>
The <Request> element is an abstraction layer used by the policy language. For simplicity of expression, this document describes policy evaluation in terms of operations on the context. However a conforming PDP is not required to actually instantiate the context in the form of an XML document. But, any system conforming to the XACML specification MUST produce exactly the same authorization decisions as if all the inputs had been transformed into the form of an <Request> element."
In summary, I believe the above considerations indicate that there is nothing of functional substance in the Multiple or Hierarchical Resource profiles that really require the presence of the XML document in the Request element, and that all the capabilities can be implemented without XPath or the XML document, and that therefore, restricting functional capabilities, such as node-naming to be represented in an explicitly XML-XPath dependent manner, while providing no alternatives is unnecessarily restricting the implementation technology to a specific form of resource representation.

i.e. the point I am trying to make is that while I have no objection to XPath methods being included as representative of a way to implement the functionality of the profiles, I do not agree that these methods are necessarily sufficient in and of themselves to represent the functional capabilities of these profiles. And for the node-naming problem, in particular, I think that the XPath syntax provides only a technology-specific way of representing the node names and that therefore an alternative string representation that is not technology-dependent is effectively required as an alternative. In addition, I also believe that the suggestion I made using URI syntax or something equivalent, meets the requirements and is transformable to XPath syntax if necessary for implementation purposes.

Comments and suggestions welcome, and I realize that I may have overlooked aspects of the problem, which might alter these conclusions, but would request that those oversights or mistakes be pointed out for consideration.


Erik Rissanen wrote:
4AC4B1B1.7050605@axiomatics.com" type="cite">Hi Paul,

See some comments inline.

Best regards,

Tyson, Paul H wrote:
No one has produced an actual use case that requires regexp on xpath resource-ids to solve. I am not inclined to jump to this sort of solution.  I have a lot of experience writing xpath expressions for xslt transformations, so I am skeptical when anyone suggests  additional functionality is required in this area, that is not already provided by well-established standards.

I still plan to start some wiki pages on these topics, but I want to introduce some other aspects of this discussion.

1. Part of the problem is that XACML overloads the concept of "resource-id" when it can be used actually as a "resource-selector" in multi-resource request for XML resources.  This causes the actual resource-id that is used during evaluation to be different than the initial resource-id (it has been "expanded" to describe the exact node).  I believe this is a defect in the specification, which should be remedied in any case.  You face this problem when you want to write (as Jan does) rules involving the string value of the resource-id.  (I still don't understand the motivation for writing these sorts of rules, but that's a different matter.)

Yes, I agree. If I understand you correctly, this is the exact same issue I am thinking of when I say that the multiple resource profile "breaks the XACML assumption that the <Request> describes a single attempted access to a single resource".

2. Related to the above point, there seems to be a gap in the current multi-resource specification, because it is not clear how the response identifies the xml node for each decision.  If PEP asks for decisions on "//*[@id=('foo','bar','baz')]"  (i.e., elements whose id attribute is 'foo', 'bar', or 'baz'), what should be the respective values of the resource-ids in the response?  They could be "//*[@id='foo']", "//*[@id='bar']", "//*[@id='baz']".  Or they could be "/chapter[1]/section[3]/para[1]", "/chapter[2]", "/chapter[2]/section[1]/fig[1]".  Assuming the PEP has xpath processing capabilities, it really shouldn't matter.  But the XACML spec should at least say something like "the returned resource-id shall be an xpath expression which, when evaluated against the original xml content, returns exactly (and only) the node on which the decision was issued".

This behavior is already required by the current specification, but could perhaps be stated more explicitly. The PDP will return the resource-id attribute specified in the individual request if the "IncludeInResult" attribute has been set to "true". And the multiple resource profile already requires that for each individual request the resource-id must consist of an XPath expression which matches exactly one node. The combined effect of this is the behavior you describe above.

3.  Much of this discussion centers around the conceptual model of multi-resource requests.  The spec says these are to be treated as a series of individual requests, and describes the required context of each derived request.  This model is normative only in concept, not for implementation--that is, a PDP must issue decisions as if this model had been followed.  The MR spec says "This Profile does NOT REQUIRE that the implementation of the evaluation of a request for access to multiple resources conform to the preceding model or that actual Individual Resource Requests be constructed." (section 2)  Therefore, the behavior of any rule evaluation that depends on a particular implementation of multi-resource requests is out of scope (and unspecified).  I believe the discussion of xpath resource-id rules falls into this category.  (I also believe the model of multi-resource decision evaluation needs to be defined better.)

Sorry, but I don't understand this point. But I do think it is relevant to discuss whether the spec can be implemented in any efficient manner, and this can affect what the specification should be like.


-----Original Message-----
From: Jan Herrmann [mailto:herrmanj@in.tum.de] Sent: Thursday, October 01, 2009 07:04
To: 'Rich.Levinson'
Cc: xacml@lists.oasis-open.org
Subject: AW: [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

Hi Rich,

I highly agree with what you said in this mail. It seems that your use case goes a bit further then the one I am thinking of. Let me try to identify the common and varying parts of our use cases.

If I understand you correctly you are not only thinking about how the resource-id values of the individual decision requests in the xml use case have to look like. You are further having the file system and URL resource use case in mind. This is something I have never thought about so far.

Further it seems that you are trying to represent the whole resource through and only through URIs in one decision request. That's also somehow different to the use case I have in mind, as in my scenario the resource (the xml doc) is always included under <content> as it is and the question of representation is always reduced to how to represent the resource-id value that must match exactly one node under content.

I think one important task is to try to identify the common or relating aspects of the different use cases and where they differ or where they are independent.

I agree that in issue 11 the namespace problem was not handled at all. Thus some little extra work is needed.

I further agree that it would be beautiful to have the same style how to define rules for different kind of resources if possible. Thus I fully share your proposal to add an alternative for representing nodes (or whatsoever) as resource-id-values or in general.

As far as I understand the Clark notation it is simply a substituted form where prefixes are replaced by the namespaces bound to them. For my use case this would work perfectly well. The question is if you want to try to force the policy writer to follow this syntax when defining the resource-id match in its rule. Further if you think of an AttributeSelector that can concatenate resource-id with an offset this implies that the AttributeSelector implementation must be able to deal with the clark syntax to :-(

In my scenario there is another possible alternative (as mentioned in the mail submitted two hours ago):
You could use a special reg-exp-On-XPath-strings function that is namespace aware and substitutes the prefixes correspondingly before doing the common reg-expr matching stuff on the resource-id attribute. This reg-exp-On-XPath-strings function is the function to test the resource-id values only.
Does your use cases require more functions that work on a URI based representation of individual resources?

Below you'll find further comments to your questions in an earlier mail.
Basic conclusion of the comments below:
allow to represent the resource in xml or through a set of attribute/value pairs (if can be shown that this realy brings advantages).

Looking forward to further discussions and comments.

Best regards


Jan Herrmann
Dipl.-Inform., Dipl.-Geogr.
wissenschaftlicher Mitarbeiter

Technische Universität München
Institut für Informatik
Lehrstuhl für Angewandte Informatik / Kooperative Systeme

Boltzmannstr. 3
85748 Garching

Tel:      +49 (0)89 289-18692
Fax:     +49 (0)89 289-18657

-----Ursprüngliche Nachricht-----
Von: Rich.Levinson [mailto:rich.levinson@oracle.com]
Gesendet: Montag, 28. September 2009 22:40
An: Erik Rissanen
Betreff: Re: [xacml] Re: XACML's limitations in the access      
control for XML
documents use case - AW: AW: [xacml] CD-1 issue #11:      
strictness of xpath

Hi Erik,

The intent of the proposal is not to replace or be better      
than XPath,
but to be an "alternative representation" for node identification as
described in section 2.0 of the profile, which if we included in the
profile as suggested in section 2.2.1, presumably would then be a
"recommended alternative representation".

The reason for the suggestion was to address the      
requirements specified
in issue 11, which contained a recommended syntax that did not
incorporate namespaces. By using the Clark notation for the      
the syntax in issue 11 can be directly incorporated to the      
URI scheme as
described in the proposal.

Once the syntax is in place then the same kinds of regexp-scoped
Policy's can be written for XML nodes as for file system and URL

Assuming the syntax and proposal is correct, it may be a useful
alternative representation in some situations, particularly      
where it may
be an objective to identify all resources w URIs, and/or      
where the mixed
XACML/XPATH syntax is a concern wrt Policy specification.


Erik Rissanen wrote:
Hi Rich,

Some of the reasons why an XPath approach could be better are:

1. XPath contains many functions and other capabilities,        
which might
not be as easily available in the URI based approach.

2. The TC would avoid the effort to define the URI        
approach. We would
need to improve the xpath approach instead, but I suspect that the
effort is smaller since we can reuse so much from xpath,        
compared with
a wholly new URI based approach.

3. It is likely that an XML resource is already available        
in XML form,
so an xpath implimentation can be applied to it directly,        
while the
URI approach requires a transformation, which could        
degrade performance.
Note that it is not true that the whole XML has to be repeated for
each resource since multiple <Attributes> elements are        
not required
with the xpath approach, and with XACML 3.0 it is        
possible to reuse
the same <Content> document for all the multiple queries.

Best regards,

Rich.Levinson wrote:
Hi Jan, et al,

I have had a busy week and not been able to respond until now,
however, looking over all the subsequent emails to the          
one to which
this is a response (
), it appears to me that there are still unresolved          
issues, and from
my perspective, there are some assertions made, with which I
disagree, about AttributeDesignators, which I thought my          
URI scheme would address, but apparently it either needs further
explanation or I am missing something that I have not          
yet understood.
In any event I would very much like to determine whether these
assertions are true or false in order that the TC be of          
a single mind
when comparing the capabilities of AttributeSelectors and

   The assertion with which I disagree is that the          
   cannot do what the AttributeSelectors can do because the
   AttributeDesignators lose the hierarchical structure.          
My response is
   that if you don't throw away the hierarchical structure when
   creating your AttributeDesignators then this          
perceived problem does
   not exist.
For the XML use case:
I can imagine that it is possible to rebuild the semantics that are
expressed through the structure of nodes through an appropriate naming of
the attributes. But it seems to be very complicated and I can't find the
advantages of transforming an originally xml encoded resource in uris
without benefits. Further this will imply special functions working on the
chosen naming-schema see below.
Why should one try to avoid AttributeSelectors at all?

If I am wrong about this, I will accept that, however, I do not
believe that my approach to the AttributeDesignators has been
considered on its merits yet, and I will try to be          
totally explicit
in this email, and I will show how I think Jan's          
proposed solution
can be completely done using only AttributeDesignators and regexp
string matching.

Having been thru some lengthy discussions earlier this          
year on the
hierarchical profile, I became quite sensitive to the node naming
issue, and one of the results of those earlier          
discussions was that
if hierarchical URIs are used to name nodes, that these          
names contain
within them the navigation necessary to locate the node, so that
using these names outside of an XML document does not lose the
structural relationships.

Using James Clark's universal name syntax          
http://www.jclark.com/xml/xmlns.htm) combined with a transform to
replace the xml document with a list of name/value pairs          
(there are
several XML to JSON xslt transformers available free,          
which I expect
could readily be adapted to produce name/value pairs in          
the format
below), where each element and attribute is identfied by its full
path expressed as universal element names. For example,          
assuming the
document you gave as an example had a namespace = "foo":

<objects xmlns:="foo">
   <book-content>.....</book-content >
   <book-content >...</book-content >

The above document would first be transformed to the          
following set of
name value pairs (ignoring whitespace):
/{foo}objects = ""
/{foo}objects/{foo}book[1] = ""
/{foo}objects/{foo}book[1]/{foo}title = "xxx"
/{foo}objects/{foo}book[1]/{foo}author = "Bob"
/{foo}objects/{foo}book[1]/{foo}id = "100"
/{foo}objects/{foo}book[1]/{foo}price = "30"
/{foo}objects/{foo}book[1]/{foo}content = "..."
/{foo}objects/{foo}book[2] = ""
/{foo}objects/{foo}book[2]/{foo}title = "yyy"
/{foo}objects/{foo}book[2]/{foo}author = "Alice"
/{foo}objects/{foo}book[2]/{foo}id = "200"
/{foo}objects/{foo}book[2]/{foo}price = "80"
/{foo}objects/{foo}book[2]/{foo}content = "..."

The next step is to define resources, which for this use          
case would
be done based on multiple resource profile, where we would have 2
resources, using Erik's shorthand:

The next step is to create xacml attributes for these          
resources using
the full universal names as AttributeIds (again w some          
resulting in the following 2 requests:
(Note: since AttributeId requires anyURI datatype, the following
percent-encoding must be applied to the AttributeId values:

   * { -> %7B
   * } -> %7D
   * [ -> %5B
   * ] -> %5D )


value = "xxx"</Attribute>

value = "Bob"</Attribute>

value = "100"</Attribute>

value = "30"</Attribute>

value = "..."</Attribute>


value = "yyy"</Attribute>

value = "Alice"</Attribute>

value = "200"</Attribute>

value = "80"</Attribute>

value = "..."</Attribute>

All the above processing to create the requests is done in the
ContextHandler, then the requests are submitted one at a          
time to the
Now the rule that gets applied to each of these requests is the

<Rule effect=Deny>
   AttributeDesignator(AttributeId =
/%7Bfoo%7Dprice) > 50 and
   AttributeDesignator(AttributeId =
function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =

Unless I am mistaken, all the logic and structure is          
retained and it
has been done purely w AttributeDesignators and regexp.
I think i can follow your approach and agree that this explicitly represents
the xml resource through URIs.
- things like ../../ will be hard to handle
- in the geo use case we have an geometry data type. This datapye is defined
by the following xml code:

<gml:Polygon srsName="http://www.opengis.net/../epsg.xml#43">
      <gml:coordinates decimal="." cs="," ts=" ">-120.000000,65.588264

Now assume you try to define a rule, following your approach, in which you
use a pointer to a polygon element in the decision request's content element
(e.g. a polgon representing the location of a building):
In very dirty/wrong XACML this will look like this:
<Rule effect=permit>
  reg-exp-string-match(resource-id, /{foo}objects/{foo}building\[\d+\]
  <Apply FunctionId=within>
    <ExtendedAttributeSelector Category=resource>
    <AttributeValue DataType=Geometry>
      <Polygon>...defining the area of the USA </Polygon>

So far no probs. Let's have a have a closer look at the AttributeSeletor,
responsible for instantiating an attribute of datatype Geometry. It will
have to go through all the URIs representing the resource and find the
relevant ones in order to instantiate the geometry attribute. This can off
course be implemented but the question is why to "flatten" an xml doc, if
afterwards, you need to rebuild parts of it.
This makes the AttributeSelector implementation unneccesarely complicated.

I think what needs to be analysed is:
- What are the advantages to transform the xml resource completely into uris
or Attribut/Value pairs respectively?
- What are the disadvantages of doing this?

The approach of leaving the xml resource as it is in the decision request
and just adding a resource-id/value pair pointing to one node implies that
you will have to use AttributeDesignators and AttributeSelectors in your
rules. Is this a disadvantage? It seems that you are trying to avoid the
selector at all. But I can't follow why.
However if it can be shown that it brings advantages to encode an xml
resource in the decision request only through Attribute/Value pairs that I
would support this as an legal option that should be added to the profile.
Of course this must bring advantages. Whithout advantages this will just
introduce another way of how to define the same rules for now reason.

Assuming the above is correct, then the points I made about the
advantages over XPath (for an enterprise looking to use          
only URIs to
identify attributes):

  1. The XML document does not need to be passed in with          
the request.
     There is no node collection, only string operations.
If I may concretise:
Case 1.
In the global request you will have a content element containing the xml
resource and an scope attribute describing a subset of this node collection
that will be subject to the access control process.
Based on this the PDP or Contexthandler will derive the individual decision
requests. Here the xml resource could be transformed as you described above
and thus you will afterwards only have attribute/value pairs.
The PEP can directly submits "already-transformed" global decision request
where the xml resource that is "normally" under <content> is replaced by a
set of Attribute/Value pairs. Further the resource-id and scope must specify
a set of these Attribute-Names. Based on this the PDP or Contexthandler will
derive the individual decision requests. The individual decision requests
will still contain the complete set of Attribute/Value pairs that represent
the xml resource and further the resource-id value will be equal to one of
these Attribute-Names.

  2. For very large XML documents, say a catalog of          
10,000 books, each
     book is processed individually independent of the          
other books, as
     compared to the XPath case, where one might expect the whole
     document has to get parsed for each of the 10,000 individual
This is only true if you don't have content dependant rules. e.g. assume you
have a rule that says permit access to books if none of the other books is
from the same author. Nevertheless I can imagine that in average less data
has to be parsed... On the other side there might be an overhead of
determining which data. Again the question: What are the advantages of transforming the resource
completely into URIs. I think if this is the central point a closer analysis
is needed.

  3. There is no paradigm shifting, or what I believe          
was referred to
     in the discussion as "shifting semantics between          
XPath and XACML
     in terms of representing the policies.
If i understand you correctly you mean that all access right semantic will
be expressed in xacml. That is necessarily true as you don't have any xml
resource in the request anymore and thus xpath predicates can't be defined
anymore. Is this an advantage? Clearly this reduces the options how the same
rule can be defined in xacml and might therefore simplify a
are-two-rules-equal test. Note that this could also be achieved if you
disallow xpath with predicates in xacml. Thus this issue can be discussed in
My experience in using a mixture of xpath predicates and xacml where
necessary (i.e. where the ac semantics can't be expressed through xpath
predicates) helps defining shorter and more readable rules. I would leave it
open to the policy administrator if he implements the semantics through
xpath predicates or xacml functions. Maybe a best practise study could
analyse this topic (next to others). In general I think such a document
might be very helpful as soon as the 3.0 specs are standardised in order to
make it easier for users to use XACML

Again, assuming the above is correct, I am not assuming          
this will be
desirable for everyone, however there may very well be          
for whom the advantages of this approach are decisive.

A couple other points are that

   * the "unsightliness" of the AttributeIds and the
     AttributeDesignators can be "covered" up by policy          
tools that
     facilitate defining policies based on XML Schemas,          
and can keep
     all the encoding details transparent to the policy          

i agree

   * the issue about basing policies on the structure of          
XML documents
     is a legitimate concern, however, if structure of documents
     change, then a legitimate case could probably made that the
     namespace associated with that structure should          
also change, which
     would mean the policy tools would need to be able          
to facilitate
     upgrading of policies to new namespaces based on          
new revs of the

Comments and suggestions welcome.



To unsubscribe from this mail list, you must leave the        
generates this mail.  Follow this link to all your TCs in        
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:


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:


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:

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]