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] CD-1 issue #11: strictness of xpath definition


Hi Erik,

I just joined the XACML TC so I have not yet read the mails that have been send over the XACML TC mailing list. Nevertheless I wanted to add a comment on the issue you just mentioned.

 

To start I'd like comment on one of statements made in one of your earlier mails (attached to your last mail):

 

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

 

I don’t agree.

Why does is it a complex task? Defining regular expressions for xpath expressions is not more complex than writing reg-expr for arbitrary strings. Further, as long as you know how your xpath expressions look like it is very easy to define the corresponding regular expressions.  

 

> >>>

> >>> 2. It is wasted effort since there are already xpath matching

> >>> functions in XACML which work perfectly well.

 

Unfortunately the xpath matching functions that are available in XACML offer only very limited functionality in the “access control for xml documents” use case. As I described in my comments during the public review period or in the presentation I gave during a Telcon in August, there are a lot of requirements that can't be met with the XACML xpath matching functions.

 

Maybe my explanations provided so far were not detailed enough. I will try to write a short summary explaining in detail the limitations when using xpath matching functions only and reason why it is advisable to do reg-exp-string matching on xpath expressions that are values of resource-id values.  

 

 

Coming back to your last mail.

 

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.

 

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.

Nevertheless I agree that this will cause unintended behaviour. Consequence is that you either

-        take care that you avoid such cases in your application environment that you are trying to protect (which shouldn’t be to hard as this is really a very special situation)

-        or you have to add a namespace attribute, that can contain a set of namespace definitions, in all XACML constructs where xpath expression are allowed. E.G. an AttributeSelector will need next to its RequestContextPath attribute a Namespace attribute that defines the namespaces of the prefixes used in the RequestContextPath value.

 

Obviously the later is a cleaner approach and is e.g. used in oracle’s xml db function signatures.

 

 

Best regards Jan

 

 

 

 

 

> -----Ursprüngliche Nachricht-----

> Von: Erik Rissanen [mailto:erik@axiomatics.com]

> Gesendet: Donnerstag, 17. September 2009 17:24

> An: Rich.Levinson

> Cc: XACML TC

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

> >>>>>

> >>>

> >>>

> >

> >

>

>

>

> ---------------------------------------------------------------------

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