OASIS eXtensible Access Control Markup Language (XACML) TC

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

  
  


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:


  
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.
  
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:
4AAA4C83.1090703@axiomatics.com" type="cite">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

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 
>  

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  

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  

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:



and



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  

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

On Thu, 2009-09-17 at 19:20 +0200, Jan Herrmann wrote:

> 
> resource one:
> 
> 

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

  


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:
4AB339DA.1040204@axiomatics.com" type="cite">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"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

RequestContextPath="foo:Book"

MustBePresent="true"

DataType="http://www.w3.org/2001/XMLSchema#string"/>


then it will match the following resource content:


<Content xmlns:foo="http://example.com/nsA">

<foo:Book>.....

</foo:Book>

</Content>


but it will not match the following


<Content xmlns:foo="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

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: 
  
4AB3D421.50103@oracle.com" type="cite">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: 
    
4AB339DA.1040204@axiomatics.com" type="cite">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"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
RequestContextPath="foo:Book"
MustBePresent="true"
DataType="http://www.w3.org/2001/XMLSchema#string"/>

then it will match the following resource content:

<Content xmlns:foo="http://example.com/nsA">
<foo:Book>.....
</foo:Book>
</Content>

but it will not match the following

<Content 
      xmlns:foo="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

  


Hi Paul,


I will defer to Jan on the particulars of the GeoXACML use case.


I hadn't really looked at the XML document aspect of the hierarchical
profile until this issue came up, however, after mulling it over a bit
I noticed a couple of aspects to it that I consider somewhat
constraining from a general perspective. I will briefly itemize what I
think are the main points to consider wrt alternative approaches:


  
XPath node matching requires the presence of the actual document
to parse and collect nodes and determine if the collected nodes are
subject to the applicable policy. In general, the hierarchical profile
considers these nodes to be actual resources, and as a result, the
fundamental XPath paradigm from an access control perspective requires
accessing the particular resource to determine if access to the
resource is allowed.


By comparison, the direct node addressing approach that I have
suggested, taken by generalizing the example Jan gave in the issue,
does not require access to the nodes, because it relies on path scoping
and matching much like scoping and matching is done with typical file
access policies, which generally control access without having to
actually access the target file.


  
  
From a performance perspective, it appears to me that very large
XML documents that have catalogs of information will generally require
some significant overhead when collecting nodes for applicability
tests.


With the direct node naming approach, this is again not a problem,
because the decisions can be made without processing the file.


  
  
For more complex policies, where XPath expressions can add a lot
of richness, in general, there is no guarantee that all the relevant
nodes to collect in order to make a decision will even be in the target
document, in which case, one will need to switch paradigms in order to
collect any nodes outside the scope of the particular XPath domain.


With the direct node naming approach, one may have more awkward
techniques required to get specific additional nodes within the target
document, but the whole policy expression paradigm can be consistent as
both xml and non-xml resources can be represented the same way using
URIs.

Again, this is being proposed as an alternative approach, for
situations where some of the above tradeoffs may make the direct
node-naming paradigm more desirable than the XPath paradigm.


I am not sure if Jan necessarily "needs" this approach to address the
particular GeoXACML concerns, but I am proposing it as a possible
solution for that use case, plus having analyzed and recognizing the
above comparisons between XPath node matching and explicit node-naming
for string matching, I think it may prove to be useful in general.


    Thanks,

    Rich



Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF09603CB4F2A@txamashur004.ent.textron.com" type="cite">
  
  
  
  
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:
    
4AB3D421.50103@oracle.com" type="cite">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:
      
4AB339DA.1040204@axiomatics.com" type="cite">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"

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

RequestContextPath="foo:Book"

MustBePresent="true"

DataType="http://www.w3.org/2001/XMLSchema#string"/>


then it will match the following resource content:


<Content xmlns:foo="http://example.com/nsA">

<foo:Book>.....

</foo:Book>

</Content>


but it will not match the following


<Content xmlns:foo="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
  
    
  

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.

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

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 

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
> 

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

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

Hi Jan,

Yes, I think there has been some miscommunication, and now we are 
talking about the same thing. ;-) See inline.

Jan Herrmann wrote:
> 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
>>
>> 

IMHO, this use-case is an extremely specialized one, and one that rarely 
arises in commercial practice.

I also have some fundamental questions about how such an approach scales 
- suppose there is some small change in the schema of tthe document, 
then the entire policy has to be redone. Tying in access control policy 
to the explicit structure of business data - whether a file system or a 
database table or an XML document is a bad idea. The use of abstract 
identifiers - such as URIs or URNs - so that a layer of abstraction is 
preserved is the standard approach in the industry.

At a minimum, I would suggest that this be solved via a separate profile 
or extension to the core XACML system.

- prateek
>
> 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:
>
> 
>
> This resource is included in a global decision request which looks 
> like this:
>
> 
>
> 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:
>
> 
>
> 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:
>
> 
>
> 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
>
> 
>
> 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:
>
> 
>
> 
>
> 
>
> 
>
> 
>
> …
>
> 
>
> …
>
> 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
>
> 
>
> 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:
>
>     

Hi All,

One complication in this whole discussion is that it mixes up several 
different use cases. There is a difference between doing access control 
on a resource which is described by an XML document and doing access 
control to sections of an XML document itself.

Let me try to illustrate:

Use case 1, XML is used to describe the attributes of a single resource:

Hi Paul,

Yes, this summarizes very well issue #16, though I cannot find anything 
about the offset in the syntax of your sample policy.

And I agree that the use case is valid and I have seen it in the real world.

I am not entirely sure yet that the offset is the best way to solve it 
(maybe it is, but I would like to think more about it).

Best regards,
Erik


Tyson, Paul H wrote:
> 1. Given this use case, are we agreed that we want to get 
> book-response when we send book-request? (Please correct any content 
> errors in these documents--I have not been using Content and xpath 
> features of XACML.)
> 2. Do we agree that current XACML 3.0 drafts (core, hier, multi) do 
> not provide features to achieve (1)? If anyone has such a solution, 
> please post. Jan's "Approach 2" uses xpath predicate, based on 
> simplicity of this example, but that is not a general solution.
> 3. book-policy.xml illustrates the xpath "offset" feature that has 
> been discussed [1] as a solution. (Again, please correct any errors.)
> 4. Where do the specs define the return value for an xpathExpression 
> resource-id? In my example, I have:
> Request: resource-id=ns1:objects/ns1:book
> Response: resource-id=ns1:objects/ns1:book[1], ns1:objects/ns1:book[2]
> Many other trivial, but equivalent, variations could have been 
> returned. But I only guessed at these from an example Erik gave, not 
> from anything I read in the specs. I would expect to find it in multi 
> section 2.2.
> Regards,
> --Paul
> [1] http://lists.oasis-open.org/archives/xacml/200909/msg00023.html
>
>     ------------------------------------------------------------------------
>     *From:* Jan Herrmann [mailto:herrmanj@in.tum.de]
>     *Sent:* Thursday, September 24, 2009 07:00
>     *To:* Tyson, Paul H; 'Erik Rissanen'; 'Rich.Levinson'
>     *Cc:* xacml@lists.oasis-open.org
>     *Subject:* XACML's limitations in the access control for XML
>     documents use case - AW: AW: [xacml] CD-1 issue #11: strictness of
>     xpath definition
>
>     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:
>
>     
>
>     This resource is included in a global decision request which looks
>     like this:
>
>     
>
>     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:
>
>     
>
>     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:
>
>     
>
>     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
>
>     
>
>     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:
>
>     
>
>     
>
>     
>
>     
>
>     
>
>     …
>
>     
>
>     …
>
>     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
>
>     
>
>     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
>
>     

  


Hi Jan, et al,


I have had a busy week and not been able to respond until now, however,
looking over all the subsequent emails to the one to which this is a
response (

http://lists.oasis-open.org/archives/xacml/200909/msg00081.html

), it appears to me that there are still unresolved issues, and from my
perspective, there are some assertions made, with which I disagree,
about AttributeDesignators, which I thought my suggested URI scheme
would address, but apparently it either needs further explanation or I
am missing something that I have not yet understood. In any event I
would very much like to determine whether these assertions are true or
false in order that the TC be of a single mind when comparing the
capabilities of AttributeSelectors and AttributeDesignators.

The assertion with which I disagree is that the
AttributeDesignators cannot do what the AttributeSelectors can do
because the AttributeDesignators lose the hierarchical structure. My
response is that if you don't throw away the hierarchical structure
when creating your AttributeDesignators then this perceived problem
does not exist.


If I am wrong about this, I will accept that, however, I do not believe
that my approach to the AttributeDesignators has been considered on its
merits yet, and I will try to be totally explicit in this email, and I
will show how I think Jan's proposed solution can be completely done
using only AttributeDesignators and regexp string matching.


Having been thru some lengthy discussions earlier this year on the
hierarchical profile, I became quite sensitive to the node naming
issue, and one of the results of those earlier discussions was that if
hierarchical URIs are used to name nodes, that these names contain
within them the navigation necessary to locate the node, so that using
these names outside of an XML document does not lose the structural
relationships.


Using James Clark's universal name syntax ("{namespace}elementname"
http://www.jclark.com/xml/xmlns.htm) combined with a transform to
replace the xml document with a list of name/value pairs (there are
several XML to JSON xslt transformers available free, which I expect
could readily be adapted to produce name/value pairs in the format
below), where each element and attribute is identfied by its full path
expressed as universal element names. For example, assuming the
document you gave as an example had a namespace = "foo":


<objects xmlns:="foo">

  <book>

    <title>xxx</title>

    <author>Bob</author>

    <id>100</id>

    <price>30</price>

    <book-content>…..</book-content >

  <book>

  <book>

    <title>yyy</title>

    <author>Alice</author>

    <id>200</id>

    <price>80</price>

    <book-content >...</book-content >

  <book>

</objects>


The above document would first be transformed to the following set of
name value pairs (ignoring whitespace):

/{foo}objects = ""

/{foo}objects/{foo}book[1] = ""

/{foo}objects/{foo}book[1]/{foo}title = "xxx"

/{foo}objects/{foo}book[1]/{foo}author = "Bob"

/{foo}objects/{foo}book[1]/{foo}id = "100"

/{foo}objects/{foo}book[1]/{foo}price = "30"

/{foo}objects/{foo}book[1]/{foo}content = "..."

/{foo}objects/{foo}book[2] = ""

/{foo}objects/{foo}book[2]/{foo}title = "yyy"

/{foo}objects/{foo}book[2]/{foo}author = "Alice"

/{foo}objects/{foo}book[2]/{foo}id = "200"

/{foo}objects/{foo}book[2]/{foo}price = "80"

/{foo}objects/{foo}book[2]/{foo}content = "..."


The next step is to define resources, which for this use case would be
done based on multiple resource profile, where we would have 2
resources, using Erik's shorthand:

<Resource>resource-id=/{foo}objects/{foo}book[1]</Resource>

<Resource>resource-id=/{foo}objects/{foo}book[2]</Resource>


The next step is to create xacml attributes for these resources using
the full universal names as AttributeIds (again w some shorthand),
resulting in the following 2 requests:

(Note: since AttributeId requires anyURI datatype, the following
percent-encoding must be applied to the AttributeId values:


  
{ -> %7B
  
} -> %7D
  
[ -> %5B
  
] -> %5D )

  


<Request>

<Subject>subject-id="Bob"</Subject>

<Resource>

<Attribute>AttributeId="resource-id"
value="/{foo}objects/{foo}book[1]"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dtitle"
value = "xxx"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dauthor"
value = "Bob"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Did"
value = "100"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dprice"
value = "30"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B1%5D/%7Bfoo%7Dcontent"
value = "..."</Attribute>

</Resource>

</Request>


<Request>

<Subject>subject-id="Bob"</Subject>

<Resource>

<Attribute>AttributeId="resource-id"
value="/{foo}objects/{foo}book[2]"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dtitle"
value = "yyy"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dauthor"
value = "Alice"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Did"
value = "200"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dprice"
value = "80"</Attribute>

<Attribute>AttributeId="/%7Bfoo%7Dobjects/%7Bfoo%7Dbook%5B2%5D/%7Bfoo%7Dcontent"
value = "..."</Attribute>

</Resource>

</Request>


All the above processing to create the requests is done in the
ContextHandler, then the requests are submitted one at a time to the
PDP.

Now the rule that gets applied to each of these requests is the
following:


<Rule effect=Deny>

  Target:

    reg-exp-string-match(resource-id, /{foo}objects/{foo}book\[\d+\]

  Condition:

    AttributeDesignator(AttributeId =
function:string-concatenate(resource-id, /%7Bfoo%7Dprice) > 50 and

    AttributeDesignator(AttributeId =
function:string-concatenate(resource-id, /%7Bfoo%7Dauthor) =
AttributeDesignator(subject-id)

</Rule>


Unless I am mistaken, all the logic and structure is retained and it
has been done purely w AttributeDesignators and regexp.


Assuming the above is correct, then the points I made about the
advantages over XPath (for an enterprise looking to use only URIs to
identify attributes):


  
The XML document does not need to be passed in with the request.
There is no node collection, only string operations.
  
For very large XML documents, say a catalog of 10,000 books, each
book is processed individually independent of the other books, as
compared to the XPath case, where one might expect the whole document
has to get parsed for each of the 10,000 individual requests.
  
There is no paradigm shifting, or what I believe was referred to
in the discussion as "shifting semantics between XPath and XACML in
terms of representing the policies.

Again, assuming the above is correct, I am not assuming this will be
desirable for everyone, however there may very well be organizations
for whom the advantages of this approach are decisive.


A couple other points are that


  
the "unsightliness" of the AttributeIds and the
AttributeDesignators can be "covered" up by policy tools that
facilitate defining policies based on XML Schemas, and can keep all the
encoding details transparent to the policy designers.
  
the issue about basing policies on the structure of XML documents
is a legitimate concern, however, if structure of documents change,
then a legitimate case could probably made that the namespace
associated with that structure should also change, which would mean the
policy tools would need to be able to facilitate upgrading of policies
to new namespaces based on new revs of the schemas.

  

Comments and suggestions welcome.


    Thanks,

    Rich




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:

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

Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

RequestContextPath="foo:Book"

MustBePresent="true"

DataType="http://www.w3.org/2001/XMLSchema#string"/>


then it will match the following resource content:


<Content xmlns:foo="http://example.com/nsA">

<foo:Book>.....

</foo:Book>

</Content>


but it will not match the following


<Content xmlns:foo="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