[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] AttributeSelector initial context as resourcenode
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: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]