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

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
> definition
> 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 namespaces,
> 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
> resources.
> 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.
>     Thanks,
>     Rich
> 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,
> > Erik
> >
> > 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 (
> >> http://lists.oasis-open.org/archives/xacml/200909/msg00081.html
> >> ), 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 suggested
> >> 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
> >> AttributeDesignators.
> >>
> >>    The assertion with which I disagree is that the AttributeDesignators
> >>    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 ("{namespace}elementname"
> >> 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>
> >>    <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>
> >>
> >> 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:
> >> <Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>
> >> <Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>
> >>
> >> The next step is to create xacml attributes for these resources using
> >> the full universal names as AttributeIds (again w some shorthand),
> >> 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 )
> >>
> >>
> >> <Request>
> >> <Subject>subject-id="Bob"</Subject>
> >> <Resource>
> >> <Attribute>AttributeId="resource-id"
> >> value="/{foo}objects/{foo}book[1]"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dti
> tle"
> >> value = "xxx"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dau
> thor"
> >> value = "Bob"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Did
> "
> >> value = "100"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dpr
> ice"
> >> value = "30"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dco
> ntent"
> >> value = "..."</Attribute>
> >> </Resource>
> >> </Request>
> >>
> >> <Request>
> >> <Subject>subject-id="Bob"</Subject>
> >> <Resource>
> >> <Attribute>AttributeId="resource-id"
> >> value="/{foo}objects/{foo}book[2]"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dti
> tle"
> >> value = "yyy"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dau
> thor"
> >> value = "Alice"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Did
> "
> >> value = "200"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dpr
> ice"
> >> value = "80"</Attribute>
> >>
> <Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dco
> ntent"
> >> value = "..."</Attribute>
> >> </Resource>
> >> </Request>
> >>
> >> All the above processing to create the requests is done in the
> >> ContextHandler, then the requests are submitted one at a time to the
> >> PDP.
> >> Now the rule that gets applied to each of these requests is the
> >> following:
> >>
> >> <Rule effect=Deny>
> >>  Target:
> >>    reg-exp-string-match(resource-id, /{foo}objects/{foo}book\[\d+\]
> >>  Condition:
> >>    AttributeDesignator(AttributeId =
> >> function:string-concatenate(resource-id, /%7Bfoo%7Dprice) > 50 and
> >>    AttributeDesignator(AttributeId =
> >> function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =
> >> AttributeDesignator(subject-id)
> >> </Rule>
> >>
> >> 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
> >> requests.

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 organizations
> >> 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 designers.

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
> >>      schemas.
> >>
> >> Comments and suggestions welcome.
> >>
> >>    Thanks,
> >>    Rich
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------------------
> 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

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