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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: RE: [xacml-comment] AttributeSelector initial context as resource node


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:erik@axiomatics.com] 
Sent: Monday, October 06, 2008 02:18
To: Tyson, Paul H
Cc: xacml-comment@lists.oasis-open.org
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
>
>
>   



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