Re: AW: AW: [xacml] Re: XACML's limitations in the access controlfor XML documents use case - AW: AW: [xacml] CD-1 issue #11: strictnessof xpath definition

[Erik Rissanen <erik@axiomatics.com>]

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
>>
>> <Rule effect=Deny>
>> Target:
>> reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\])
>>
>> with
>>
>> <Rule effect=Deny>
>> Target:
>> xpath-node-equal(resource-id, /objects/book)
>>     
>
>
> I am not sure but I think I identified a point of misunderstanding your last
> mails. I always thought that you are trying to say that all access semantics
> can be expressed using the xpath-node match functions only. Reading your
> last mail carefully I realized that you are just wondering whether the
> target part of a rule could be written in a different way.
>  
> As you said the Target definitions below are semantically equal (assuming
> that the resource-id values of the individual decision requests have the
> correct syntax e.g. /objects[1]/book[1] or /objects[1]/book[2]).
> - reg-exp-string-match(resource-id, /objects\[\d+\]/book\[\d+\]) 
> - xpath-node-equal(resource-id, /objects/book)
>
> What can be discussed is which of the two options is more appropriate (e.g. 
> Which can be evaluated more efficiently? Is the namespaces and normalform
> issue a too hard problem?). Nevertheless I must confess that through this
> alternative the reg-exp-string-match use on xpath could be avoided.
>   

Yes, this has been the point I have been trying to make with issue #11. 
By using xpath-node-equal, then it is not necessary to define a strict 
form of xpaths generated by the PDP, and we avoid the problems of 
defining another matching language.

Agreed, there might be performance reasons to not use xpath, but I have 
not done any work on this. However, until it is shown that xpath really 
has performance issues, I would like to avoid defining another matching 
language, considering how much work this would do and the risk of making 
a mistake doing so.

> The important point I tried to point out is, that the xpath functions ONLY,
> allow only for a pretty coarse grained specification of the resources=nodes
> the rule is referring to.
>
> In order to define the resources a rule is referring to on a more
> fine-grained, content dependant level you have to add conditions like the
> following:
>  AttributeSelector(concat(resource-id, /price/text()) > 50 and
>  AttributeSelector(concat(resource-id, /author/text()) =
>  AttributeDesignator(subject-id)
>
> Only through the use of this "new/extended" selector you get the needed
> expressiveness (fine-grained, content dependant rules). Further it is very
> important that resource-id matches exactly one node.
>   

Yes, this is correct. Without an offset, or something else, this cannot 
be done very well by XACML. This is issue #16 on the list. I have tried 
to keep issues #11 and #16 separate, since I hope you now can see that 
they are mostly independent from each other.

> Did I understand you correctly or are you further looking for an example
> where the xpath functions in general are not enough?
>   

I think we are now in agreement of what the issues are.

Best regards,
Erik