[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] CD-1 issue #11: strictness of xpath definition
Hi again Rich, Just to give a simple example of some the complexities we would have to tackle if we start doing string matching on xpath expressions, consider these two expressions: <AttributeValue DataType="...:xpath-expression" xmlns:foo="example.com/nsA" xmlns:bar="example.com/nsB"> foo:Title[1]/bar:Name[1] </AttributeValue> and <AttributeValue DataType="...:xpath-expression" xmlns:foo="example.com/nsC" xmlns:bar="example.com/nsD"> foo:Title[1]/bar:Name[1] </AttributeValue> Both would match equally against string/regexp functions, but they are entirely different xpaths and refer to different resources. Best regards, Erik Erik Rissanen wrote: > Hi Rich, > > Yes, I agree XML documents are well formed hierarchies, but I don't > understand why another naming scheme is needed? What is it that cannot > already be done with xpath as the naming scheme and xpath functions to > work with them. Agreed, with xpath as the naming scheme the names are > not unique, but is that necessary? I don't see that it is, at least > not in the scope of the hierarchical profile we have. > > One reason for why such a naming scheme should not be established, > would be if such a naming scheme doesn't provide anything of value. > > And if we are going to need a naming scheme, I doubt we are the first > one to think of this problem, so defining our own subset of xpath is > probably not the right way to go. At least not until we have done a > thorough research on the issue. > > Best regards, > Erik > > > Rich.Levinson wrote: >> Hi Erik, >> >> I understand your concern re: xpath, in particular, however, XML >> documents are well formed hierarchies and there is no reason why a >> standard naming scheme for the nodes that would incorporate the type >> of scoping used for filename and URL policies should not be >> established. In the absence of such a std, xpath expressions may be a >> reasonable place to start, esp. w a limited syntax such as that was >> proposed by Jan in the original issue. >> >> Thanks, >> Rich >> >> >> Erik Rissanen wrote: >>> Rich, >>> >>> I maintain that the paradigm of matching xpath expressions with >>> regular expressions is flawed. XPath is a matching language in >>> itself, and we should not make an attempt to define another layer of >>> string matching on top of it because: >>> >>> 1. It is a complex task to do so, and it is very easy to make a >>> mistake. >>> >>> 2. It is wasted effort since there are already xpath matching >>> functions in XACML which work perfectly well. >>> >>> I agree that it could be a good idea to suggest how an >>> implementation could construct the xpath expressions in order to >>> help implementers and users alike, but that should not be normative. >>> But I think that kind of advice belongs to some implementation guide >>> document, rather than the standard specification itself. >>> >>> Best regards, >>> Erik >>> >>> >>> Rich.Levinson wrote: >>>> Significant changes have been proposed to the hierarchical/multiple >>>> profiles and some related changes in the core as well as outlined >>>> in these messages: >>>> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00001.html >>>> >>>> http://lists.oasis-open.org/archives/xacml-comment/200907/msg00000.html >>>> >>>> as well as the OGC Engineering Report document attached to the >>>> first message. >>>> >>>> Speaking for myself and as member of the XACML TC, I much >>>> appreciate the effort that went into the analysis of the core spec >>>> and these profiles by the GeoXACML group, and particularly, Jan >>>> Herrmann (Chair: GeoXACML SWG), who presented this material to us >>>> this summer (info for pres in these minutes): >>>> http://lists.oasis-open.org/archives/xacml/200907/msg00017.html >>>> >>>> The issues raised in these emails have been catalogued in the >>>> spreadsheet prepared by Erik: >>>> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html >>>> as well as other issues that have been raised in the public review >>>> period. >>>> >>>> I believe there are significant substantive issues that remain to >>>> be addressed, in particular, in the hierarchical profile, in the >>>> area of XML document resources, that were not visited within the >>>> scope of changes to the hierarchical profile in 3.0. >>>> >>>> ***************************************************************** >>>> This particular issue, CD-1 #11 appears to me to be a good starting >>>> point to begin to address the overall issue of the handling of XML >>>> resources in the hier/multiple profiles. I will repeat the text of >>>> the issue here, and after that, comment on it, along with some >>>> starting suggestions as to how to address it (actually, I have >>>> edited it slightly for readability and inserted a couple clarifying >>>> notes that I needed to understand a couple of points): >>>> >>>> ******************************************* >>>> Issue CD-1 #11: >>>> >>>> Comment 2: Line 56: interoperability problem >>>> “[XPath] expressions can be used to reference nodes in this >>>> document in a standard way, and can provide unique representations >>>> for a given node in the document.” ([3], S. 3). >>>> Forcing to use XPath expressions referring to exactly one node in >>>> the <ResourceContent> element limits the representation >>>> possibilities, which is a step in the right direction. >>>> But this still leaves some flexibility for no real reason and >>>> might therefore cause interoperability problems. Example: >>>> >>>> A resource-id attribute value in an individual decision request >>>> might be: >>>> >>>> /Request[1]/Resource[1]/ResourceContent[1] >>>> /wfs:FeatureCollection[1]/gml:featureMember[1]/Building[1] >>>> >>>> A rule e.g. allowing access to building nodes will have a >>>> predicate like the following: >>>> >>>> regexp-string-match( resource-id, >>>> /Request[1]/Resource[1]/ResourceContent[1] >>>> /wfs:FeatureCollection\[\d+\] >>>> /gml:featureMember\[\d+\] >>>> /Building\[\d+\]$) >>>> >>>> By using such a predicate all decision requests referring to >>>> “Building” nodes will match and the rule will get evaluated. >>>> (note: $ (dollar) Matches at the end of the string the >>>> regex pattern is applied to. Matches a position rather than a >>>> character. Most regex flavors have an option to make the >>>> dollar match before line breaks (i.e. at the end of a line in >>>> a file) as well. Also matches before the very last line >>>> break if the string ends with a line break. >>>> http://www.regular-expressions.info/reference.html ) >>>> >>>> In this example we used the abbreviated XPath syntax to refer to >>>> exactly one node. >>>> In case the Context Handler uses unabbreviated XPath syntax when >>>> deriving the individual decision requests from a global decision >>>> request the rule won’t match any more. >>>> (note: abbreviated syntax in xpath spec: >>>> http://www.w3.org/TR/xpath#path-abbrev >>>> refers to prefixes like child:: etc. >>>> >>>> "The most important abbreviation is that child:: can >>>> be omitted from a location step. In effect, child is the >>>> default axis. >>>> For example, a location path div/para is short for >>>> child::div/child::para.") >>>> >>>> Conclusion: >>>> In order to get a unique representation for a node in the >>>> document it should be specified more precisely which syntax the >>>> XPath values of the resource-id attribute have to conform. >>>> We recommend to use a syntax as shown in the example (i.e. >>>> /elementNodeName[integer]/../elementNodeName [integer] >>>> in case of element nodes and >>>> /elementNodeName[integer]/../@attributeNodeName >>>> in case of attribute nodes. >>>> Additionally the question is whether the XPath expressions >>>> should always refer to the <xacml-context:Request> element as its >>>> context node or to the content element that is additionally >>>> identified through the category attribute? >>>> If you choose option one >>>> (i.e. the <Request> element is the context node), >>>> then XPath expressions will always start with >>>> /Request... >>>> (c.p. e.g. line 4907 in the core XACML 2.0 specification). >>>> >>>> Remark: Note that it is not possible to use the XPath node >>>> matching function in order to make the exact form of the xpath >>>> expression irrelevant. >>>> The reason is that XPath node match functions imply certain >>>> limitations in our use case like: >>>> >>>> • only predicates supported by XPath can be used to define >>>> content dependant authorizations à limited expressiveness >>>> >>>> • no pointers to XACML decision request data inside an XPath >>>> predicate >>>> (e.g. permit access if /bulding[owner = subject-id]) >>>> àlimited expressiveness >>>> >>>> • filtering is not possible >>>> >>>> – the XACML decision response refers to the Web Service request >>>> or response as a whole >>>> >>>> ******************************************* >>>> >>>> The above looked ok when I inserted it, hopefully the editors along >>>> the way don't mess it up too much. :) >>>> >>>> In any event, here are a couple of initial comments on the issue: >>>> >>>> 1. From the above expression, where >>>> regexp-string-match(resource-id, "xpath string") is given as a >>>> sample predicate for a Rule, and the follow-up comments on >>>> "recommended syntax" for the xpath expressions, it is clear to >>>> me at least, that one significant paradigm for XML resource >>>> processing is to treat the xpath expression as a string, and as >>>> an instance of an explicit identity name for a resource. >>>> Similarly, regular expressions can be applied to this syntax for >>>> the purpose of "scoping" tests to determine whether the Rule is >>>> applicable. >>>> IMO, this comes very close to putting the xpath string on the >>>> level of a URI, and in fact, w escape sequences, I think we can >>>> probably consider it an instance of the URI strings described in >>>> section 2.2 of the hierarchical profile. Therefore, part of my >>>> suggested change to the profile is to consider this paradigm in >>>> the context of representation of the identities associated with >>>> XML document resources. >>>> 2. This also raises an issue of processing of XML document >>>> resources. In particular, is it necessary to always send the >>>> whole XML document in each of the detailed requests, which >>>> probably entails significant xml processing overhead, in >>>> general, even considering optimizations for non-xml processing >>>> of the data. In some ways, I see this as equivalent to sending a >>>> complete directory listing of all the files in a file system >>>> with each request for access to a file. While, that is ok in >>>> some situations (maybe?), I expect people will look to >>>> alternatives, esp.in the area of send just the file name that is >>>> being requested and setting policies to parse the file name >>>> against scope file name expressions of the type described in the >>>> multiple resource profile. >>>> The bottom line here is that I agree that there should be >>>> standard xpath expression syntaxes specified as a best practice >>>> for specific installations. Then given the standard syntax, >>>> policies can be specified treating xpath expressions like file >>>> names and determining if the xpath expression identifying the >>>> requested resource, falls within the scope of an xpath >>>> expression in the policy describing the nodes that particular >>>> expression is targeting. >>>> The recommendation is to give an example of this type of scoping >>>> in section 2.1 and refer to section 2.2 as the broader context >>>> within which the paradigm may be viewed as URI scoping >>>> expressions. >>>> >>>> Please regard the above as an initial proposal which describes >>>> roughly the type of changes that I think can be put in the profile >>>> to address the issue that has been raised. >>>> >>>> Thanks, >>>> Rich >>>> >>>> >>>> >>>> Erik Rissanen wrote: >>>>> The issue number refers to the XLS-sheet found in this email: >>>>> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html >>>>> >>>>> The commenter says that the way an xpath expression identifying a >>>>> resource is not defined strictly enough that the expression can be >>>>> used in string match functions. >>>>> >>>>> However, the constructed xpath expression is intended to be used >>>>> with xpath match functions, where the exact, characted by >>>>> character, form does not matter. >>>>> >>>>> I propose that we make no change. >>>>> >>>>> 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 >>>>> >>> >>> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]