[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]