Paul,
I misunderstood your use case completely. Sorry about that. :-)
Another way to do it would be to concatenate the resource-id xpath with
the resource specific xpath with some concatenation function. However
there are currently no such concatenation functions which handle
namespaces well.
I need to think more about this.
Regards,
Erik
Tyson, Paul H wrote:
> I understand the change in xpath context from <Request> in 2.0 to
> <Content> in 3.0. I suggested an additional refinement that would make
> it easier to write context-based rules for XML resources, as described
> in HIERARCHICAL 4.2.
>
> I'm trying to determine if the XACML 3.0 core, multiple, and
> hierarchical specifications address the use case I described.
>
> To further describe the use case, here is a sample Request:
>
> <Request xmlns:mns="my-namespace">
> <Attributes Category="...resource">
> <Content>
> <node xmlns="my-namespace" id="n1">
> <att name="att1">foo</att>
> <node id="n2">
> <att name="att1">foo</att>
> <att name="att2">abc</att>
> </node>
> <node id="n3">
> <att name="att1">bar</att>
> <att name="att2">xyz</att>
> </node>
> </node>
> </Content>
> <Attribute
>
> AttributeId="urn:oasis::names:tc:xacml:1.0:resource:resource-id">
> <AttributeValue
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">mns:no
> de//mns:node</AttributeValue>
> </Attribute>
> <Attribute
> AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string">XPath-expression</Att
> ributeValue>
> </Attribute>
> </Attributes>
> <Attributes
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
> <Attribute
> AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string">child-of</AttributeVa
> lue>
> </Attribute>
> </Attributes>
> </Request>
>
> I want decisions on nodes n2 and n3. I expect n2 to be "Permit" and n3
> to be "Deny", based on the policy described previously in thread (assume
> Target of policy includes action-id="child-of").
>
> I don't see how this can be accomplished (in full generality) without
> the ability to start <AttributeSelector> xpath evaluation from the
> <Content> descendant on which the decision is wanted.
>
> --Paul
>
> -----Original Message-----
> From: Erik Rissanen [mailto:]
> Sent: Monday, October 06, 2008 02:18
> To: Tyson, Paul H
> Cc:
> Subject: Re: [xacml-comment] AttributeSelector initial context as
> resource node
>
> Paul,
>
> In XACML 2.0 the xpath of an AttributeSelector starts at the request
> context. We changed this for 3.0 because a clean separation between the
> attributes which AttributeSelectors respective AttributeDesignators can
> refer to allows for optimizations in the PDP which are not possible to
> do if xpaths may refer to anything in the request.
>
> In particular, if xpaths may refer to anything, then it is necessary to
> construct a full XML representation of the entire request context,
> including any potentially dynamically resolvable attributes at the
> moment of the first xpath evaluation. And for the multiple resource
> profile it would be necessary to perform XML manipulation to generate
> actual XML representations of each individual request.
>
> If you want to refer to the "regular" attributes with xpaths, you can
> always put the equivalent XML inside the <Content> element.
>
> Regards,
> Erik
>
> Tyson, Paul H wrote:
>
>> Consider adding an optional attribute on <AttributeSelector> to start
>> at the resource node instead of the <Content> element. This would
>> only have to be supported under a hierarchical profile. The attribute
>>
>
>
>> could be named "ResourceContextPath", and would be used instead of
>> "RequestContextPath" when the evaluation should start from the node on
>>
>
>
>> which a decision is wanted.
>>
>> When writing policies for hierarchical resources, it is sometimes
>> convenient to express a condition based on the value of another node
>> in the request content, relative to the resource node on which the
>> decision is requested.
>>
>> <AttributeSelector> only allows xpath expressions with initial context
>>
>
>
>> of the <Content> request element.
>>
>> For example, suppose the resource content looks like this:
>>
>> <node xmlns="my-namespace">
>> <att name="att1">foo</att>
>> <node>
>> <att name="att1">foo</att>
>> <att name="att2">abc</att>
>> </node>
>> <node>
>> <att name="att1">bar</att>
>> <att name="att2">xyz</att>
>> </node>
>> </node>
>>
>> I have a business rule that says no node with att1="bar" should have
>> an ancestor node whose att1="foo". (Conversely, no node with
>>
> att1="foo"
>
>> should have a descendant with att1="bar". But I don't want a decision
>>
>
>
>> on the ancestor, I want a decision for each descendant.)
>>
>> I want decisions on all nested nodes, so my request will include the
>> appropriate scope and resource-id attributes for an xpath-expression
>> multi-resource request.
>>
>> The problem is writing the rule. Nodes can be nested to any depth.
>> The rule can be stated as: "if the resource att1='bar', and any
>> ancestor node has att1='foo', then deny; otherwise permit". This goes
>>
>
>
>> directly into a XACML Policy with two Rules. The essential parts of
>> the policy might look like this (using the proposed
>> "ResourceContextPath" attribute on AttributeSelector):
>>
>> <Policy xmlns:mns="my-namespace"
>> RuleCombiningAlgId="...first-applicable">
>>
>> <Target>
>> <AnyOf>
>> <AllOf>
>> <Match
>> MatchId="urn:oasis:names:tc:xacml:3.0:xpath-node-match">
>> <AttributeValue
>>
>> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
>>
>>
>>
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
>
>>
>>
>>> mns:node//mns:node</AttributeValue>
>>>
>>>
>> <AttributeDesignator
>>
>> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
>> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
>>
>> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>
>> </Match>
>> </AllOf>
>> </AnyOf>
>> </Target>
>>
>> <Rule RuleId="deny-bar-if-ancestor-foo" Effect="Deny">
>> <Target>
>> <AnyOf>
>> <AllOf>
>> <Match
>>
>> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>> <AttributeValue
>>
>>
> DataType="http://www.w3.org/2001/XMLSchema#string">bar</AttributeValue>
>
>> <AttributeSelector
>> ResourceContextPath="mns:att[@name='att1']
>> DataType="http://www.w3.org/2001/XMLSchema#string"
>> MustBePresent="false"
>>
>> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"/>
>> </Match>
>> <Match
>>
>> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>> <AttributeValue
>>
>>
> DataType="http://www.w3.org/2001/XMLSchema#string">foo</AttributeValue>
>
>> <AttributeSelector
>>
>> ResourceContextPath="ancestor::mns:node/mns:att[@name='att1']"
>> DataType="http://www.w3.org/2001/XMLSchema#string"
>> MustBePresent="false"
>>
>> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"/>
>> </Match>
>> </AllOf>
>> </AnyOf>
>> </Target>
>> </Rule>
>>
>> <Rule RuleId="permit-otherwise" Effect="Permit"/>
>>
>> </Policy>
>>
>> If there is another way to address this use case using existing XACML
>> features I would like to know about it.
>>
>> --Paul Tyson
>>
>>
>>
>>
>
>
