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