OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-users] xpath access control


Thank you for your answers.

Argyn, I already thought of regular expressions and they can do a great
job, if all queries that may be used in a certain application setting
are known a priori. I believe they are insufficient if we allow ad-hoc
queries, since each nodeset may be selected using syntactically
different queries. For example some axis navigations I need to deal with
are hard to handle.

Anne's examples below illustrate my problem very well. In case of
Document 1 both queries are semantically equl, imho, since both select
the same node, but not in Document 2 (How can we know /A/B[2] looks
like?). Or referring to XPath axes you could use queries like
//Employee/Wage/@IntValue < 2000 and
//Employee/Name/sibling:node()/@IntValue < 2000, which may but need not
necessarily aim at the same node set. In my setting, I assume that if a
user has access to node A/B, then A/B/C would be legal, while A or A/D
would be rejected.

Anne, I agree with you on restricting the syntax to absolute path
queries, though I do not want to abandon operators and element orders as
shown in your example unless I absolutely have to. To a certain extent,
a query can be "reduced" or rewritten by eliminating features, e.g.
/A/B/../C -> A/C (as well as the parent axis). I just thought there is a
general solution to this problem and the xpath-node-math function gave
me some hope ;) (since I'm using XACML anyway) but it seems we have to
agree on some tradeoffs in this case.

Thanks for the paper reference btw.
Best regards


Anne Anderson - Sun Microsystems schrieb:
> Argyn,
>
> [I haven't checked my XPath syntax below, but I hope the idea is clear.]
>
> As an example of the problem, does /A/B[@x="5"]/C
> select the same nodeset as /A/B[2]/C ?
>
> They do in document 1, but not in document 2:
>
> Document 1:
>   <A>
>     <B x="6">
>        <C/>
>     </B>
>     <B x="5">
>        <C/>
>     </B>
>   </A>
>
> Document 2:
>   <A>
>     <B x="5">
>        <C/>
>     </B>
>     <B x="6">
>        <C/>
>     </B>
>   </A>
>
> The only solution to this problem is limiting your XPath expression
> syntax such that any two expressions select the same nodeset if and
> only if the expressions are syntactically equivalent.  I have no
> proof, but I hypothesize that it is sufficient to require absolute
> expressions, and disallow query operators and element order
> specifiers.  I would be interested in a proof of this or any other
> proposed limited syntax to solve this problem!
>
> [1] proves that the intersection of two XPath expression is equal to
> an XPath expression that merges the constraints at each level: i.e.
> the intersection of the above two is /A/B[@x="5"]&[2]/C (or whatever
> the correct syntax for that is), but that is not the problem to be
> solved here.
>
> Regards,
> Anne Anderson
>
> [1] B.C. Hammerschmidt, M. Kempa, V. Linnemann, "On the Intersection
> of XPath Expressions", Proceedings of the 9th International Database
> Engineering & Application Symposium (IDEAS 2005).  July 2005,
> Montreal, Canada.
>
> Argyn wrote On 11/30/06 11:35,:
>> On 11/30/06, Wolfgang Schreiner <wolfgang.schreiner@ec3.at> wrote:
>>
>>> Hi all,
>>>
>>> Following problem: I would like to control access to a set of XML
>>> documents via XPath 2.0 queries. XML fragements, which are allowed to
>>> being accessed are specified by XPath 2.0 statements as well. What I
>>> need is a method to determine whether 2 XPath statements are
>>> semantically equal or similar
>>
>>
>> i'm not sure what you mean by that. wouldn't a simple regexp match
>> work in this case?
>>
>>> , before executing the query and having to
>>> post-filter the result. What is the best way to achieve this? Does the
>>> XACML xpath-node-match function solve this problem?
>>
>>
>> it only checks if the resulting nodes are the same, imho. it may not
>> be what you are looking for
>>
>>> Is there an
>>> implementation to it? I think the Sun implementation does not include
>>> XPath functions?
>>
>>
>> sun and other implementations have xpath functionality as of xacml 2.0
>>
>> argyn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
>>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]