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 resourcenode


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]