[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: 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 Erik,
see comments below.
greetings jan
> -----Ursprüngliche Nachricht-----
> Von: Erik Rissanen [mailto:erik@axiomatics.com]
> Gesendet: Donnerstag, 24. September 2009 15:42
> An: Jan Herrmann
> Cc: PTyson@bellhelicopter.textron.com; 'Rich.Levinson'; xacml@lists.oasis-
> open.org
> Betreff: Re: 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 Jan,
>
> Thanks for the clarifications.
>
> But I still don't understand why it is necessary to use string matching
> on xpath expressions, rather than xpath match functions. Can you give an
> example of where the xpath functions are not enough?
>
> And just to clarify, when I say xpath functions, I don't mean this:
>
> integer-greater-than
> (integer-one-and-
> only(AttributeSelector(count(/objects/book[price/text()>50
> AND author/text() = AttributeDesignator(subject-id)])), 0).
>
> I am referring to the xpath functionality in XACML. So, I mean that you
> could replace the following
>
> <Rule effect=Deny>
> Target:
> reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\])
>
> with
>
> <Rule effect=Deny>
> Target:
> xpath-node-equal(resource-id, /objects/book)
I am not sure but I think I identified a point of misunderstanding your last
mails. I always thought that you are trying to say that all access semantics
can be expressed using the xpath-node match functions only. Reading your
last mail carefully I realized that you are just wondering whether the
target part of a rule could be written in a different way.
As you said the Target definitions below are semantically equal (assuming
that the resource-id values of the individual decision requests have the
correct syntax e.g. /objects[1]/book[1] or /objects[1]/book[2]).
- reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\])
- xpath-node-equal(resource-id, /objects/book)
What can be discussed is which of the two options is more appropriate (e.g.
Which can be evaluated more efficiently? Is the namespaces and normalform
issue a too hard problem?). Nevertheless I must confess that through this
alternative the reg-exp-string-match use on xpath could be avoided.
The important point I tried to point out is, that the xpath functions ONLY,
allow only for a pretty coarse grained specification of the resources=nodes
the rule is referring to.
In order to define the resources a rule is referring to on a more
fine-grained, content dependant level you have to add conditions like the
following:
AttributeSelector(concat(resource-id, /price/text()) > 50 and
AttributeSelector(concat(resource-id, /author/text()) =
AttributeDesignator(subject-id)
Only through the use of this "new/extended" selector you get the needed
expressiveness (fine-grained, content dependant rules). Further it is very
important that resource-id matches exactly one node.
Did I understand you correctly or are you further looking for an example
where the xpath functions in general are not enough?
Best regards
jan
>
> (Note that I am ignoring the offset issue in this case, so assume that
> there is only one book for now)
>
> The xpath-node-equal function would treat namespaces properly, and you
> don't depend on any particular form of the xpath expression in the
> resource-id attribute.
>
> Best regards,
> Erik
>
>
> Jan Herrmann wrote:
> > Hi Erik,
> >
> > thanks for your detailed reply. I added comments inline.
> > Best Regards
> > Jan
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Erik Rissanen [mailto:erik@axiomatics.com]
> >> Gesendet: Donnerstag, 24. September 2009 14:35
> >> An: Jan Herrmann
> >> Cc: PTyson@bellhelicopter.textron.com; 'Rich.Levinson';
> 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
> >>
> >> Hi Jan,
> >>
> >> Thanks for the effort you put into explaining this with such detail.
> >>
> >> I can see that you mix two separate issues in here. One of them I agree
> >> is a real problem, though I am not sure what the ideal solution would
> be.
> >>
> >> The first issue which you explain very well is that is difficult to
> >> write XACML rules which interrelate XML content within a single XML
> >> resource among multiple XML resources because the resources "mix up"
> >> with each other. You propose an offset to the AttributeSelector to fix
> >> this.
> >>
> >
> > I am not sure if I understand this but your conclusion sounds good. I
> > believe that an AttributeSelector with a child element instead of the
> > RequestContextPath attribute will be very powerful. Note that this issue
> is
> > closely related to the second issue.
> >
> >
> >> This issue is listed as number 16 among the comments we received during
> >> the public review. See here:
> >>
> >> http://lists.oasis-open.org/archives/xacml/200909/msg00023.html
> >>
> >
> > That is one of the comments I made during the public review phase. I was
> > describing it in more detail in the last mail because Paul asked for
> more
> > explanations...
> >
> >
> >
> >> I think we should do something about it, but I would like to wait past
> >> 3.0 since 3.0 has already been so delayed. I am not sure the right fix
> >> is the offset, so opening up technical work on this would delay 3.0
> even
> >> more. Whatever solution we make could be done as a separate profile in
> >> the next batch of 3.0 documents (like metadata and so on).
> >>
> >> To me the fundamental problem in this use case is that an XML resource
> >> like this breaks the XACML "assumption", if you permit the expression,
> >> that the request describes a single access request. The multiple
> >> <Resource>/<Attributes> elements approach does not have the same
> >> problem. Consider the following multiple request:
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>resource-id=documentA</Resource>
> >> <Resource>resource-id=documentB</Resource>
> >>
> >> The above request is shorthand for a series of XACML requests, and an
> >> individual request like this would never reach the actual policy
> >> processing in the PDP, rather it would be pre-processed into these two
> >> requests:
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>resource-id=documentA</Resource>
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>resource-id=documentB</Resource>
> >>
> >> Note how each individual request is about a single access request with
> a
> >> single subject and single resource, with no risk of mixing the
> resources
> >> up in the matching operations.
> >>
> >> However, consider this multiple XML resource request instead:
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>
> >> scope=xpath-expression
> >> resource-id = book
> >> <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>
> >> </Resource>
> >>
> >> Now, this would be pre-processed into two separate requests like this:
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>
> >> resource-id = book[1]
> >> <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>
> >> </Resource>
> >>
> >> and
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>
> >> resource-id = book[2]
> >> <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>
> >> </Resource>
> >>
> >> Note how both these requests contain data about all resources, and the
> >> data can therefore be mixed up. The offset is one way to handle this,
> >> but, maybe it would be better to trim away the data of the other
> >> resources instead? Something like this:
> >>
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>
> >> resource-id = book
> >> <book>
> >> <title>xxx</title>
> >> <author>Bob</author>
> >> <id>100</id>
> >> <price>30</price>
> >> <book-content>...</book-content >
> >> <book>
> >> </Resource>
> >>
> >> and
> >>
> >> <Subject>subject-id=alice</Subject>
> >> <Resource>
> >> resource-id = book
> >> <book>
> >> <title>yyy</title>
> >> <author>Alice</author>
> >> <id>200</id>
> >> <price>80</price>
> >> <book-content >...</book-content >
> >> <book>
> >> </Resource>
> >>
> >> I don't know, which is better, but the second alternative would be
> >> closer to the original idea of XACML describing the attributes of a
> >> single attempted access, and there is less risk that a policy author
> >> would mix up the resources. However, I am sure there are complications
> >> with this approach as well.
> >>
> >
> > The current version of the multiple and hierarchical resource profile
> > describes both approaches and from my point of view the first approach
> is
> > more relevant/interesting in the xml-resource use case.
> > The profiles say that: The decision request should stay the same with
> two
> > exceptions:
> > 1. the resource-id Attribute should match exactly one individual node
> and
> > 2. the scope Attribute should be absent.
> >
> > I would leave the profiles like this in this aspect. You can't divide
> the
> > xml-resource like you did for the book example in general. Each
> individual
> > element-, attribute- and text-node are the real resources. The reason
> why
> > they should still all be in the individual decision requests is that it
> is
> > necessary to define content dependant rights that depend on other
> > values/nodes/resources.
> > Following the multiple and hierarchical resource profile of XACML
> Version
> > 2.0 I strongly suggest to leave this like it is currently specified.
> >
> > I think what may be confusing is the use of the word resource for
> different
> > things.
> >
> > From my point of view a resource is a xml node. The xml code included
> under
> > the content element (of category resource) is a set of resources -
> > hierarchically organised and consisting of multiple nodes and thus both
> > profiles apply. A XACML decision request can refer to multiple
> "resources"
> > in two different ways.
> > The first as you explained above really has two different <Resource>
> > elements. In fact I think that this was changed in xacml 3.0 ..but
> that’s
> > not important here and this case is clear anyway.
> >
> > Second and more interesting from my point of view is the situation where
> you
> > have the real resources under the <content> element.
> >
> > If you take e.g. an Web Service request and response than both the
> requests
> > and the response can be XML documents (think e.g. of an XML based SQL
> > interface). In this use case a ws-request will be included in the XACML
> > decision request under content if you do access control on the web
> service
> > request. Similar if you do access control on the web-service response
> than
> > in a completely independent xacml decision request you add the web
> service
> > response to the xacml decision request under a content element...
> >
> >
> >> I am trying to say is that I have concerns about making a significant
> >> change like that without considering all the alternatives thoroughly.
> >>
> >
> > I agree but I would take the position that it took nearly 5 years to
> come up
> > with a new XACML version so it is worth to spend some extra time (O(1-2
> > weeks) to add powerful features. By the way, within the OGC we did
> already a
> > lot of thinking in this direction in the last 5 years. Further I think
> that
> > the changes needed in the profiles are more minor but are still
> important
> > changes enhancing the expressivness. In fact as I read the current
> version
> > of the profiles, the baseline is already set up and thus it just needs
> some
> > further guidelines.
> >
> >
> >
> >> Now, the second issue which was debated a lot on the list last week was
> >> the use of string matching vs xpath matching. See the thread here:
> >>
> >> http://lists.oasis-open.org/archives/xacml/200909/msg00020.html
> >>
> >> You use string matching in your example, but it would work better with
> >> the xpath functions instead, since you would avoid all the
> >> namespace/canonical form issues which stem from string matching.
> >>
> >
> > If I could use the xpath functions i would be happy but as i tried to
> > explain they do not offer enough expressiveness. I agree that the
> > namespace/canonical form issues have to be thought of for
> interoperability
> > reasons but as was said in this thread :
> > "When using XACML 3.0 functions related to XPath you MUST include
> namespace
> > definition(s)" so the namespace issue seems to be addressed already.
> > Further the canonical form thing is just a syntactical and more or less
> > obvious decision that everybody has to agree on.
> >
> >
> >
> >> I still
> >> don't see the need of a strict format for xpath expressions generated
> by
> >> the PDP.
> >>
> >
> > that is just the consequence and only needed in order to ensure that a
> pdp
> > from vendor A and the rules defined by distributed administrator
> (writing
> > rules for different pdp implementations) will be interoperable .
> > Upfront it is important to agree that xpath is not powerfull enough to
> > express access rights in the xml resource use case.
> >
> >
> > Best regards jan
> >
> >
> >> Best regards,
> >> Erik
> >>
> >>
> >> Jan Herrmann wrote:
> >>
> >>> 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:PTyson@bellhelicopter.textron.com]
> >>> Gesendet: Montag, 21. September 2009 16:24
> >>> An: Rich.Levinson; Erik Rissanen; Jan Herrmann
> >>> Cc: xacml@lists.oasis-open.org
> >>> 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:rich.levinson@oracle.com]
> >>> Sent: Sunday, September 20, 2009 18:41
> >>> To: Erik Rissanen; Jan Herrmann
> >>> Cc: xacml@lists.oasis-open.org
> >>> 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
> >>>
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> 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]