MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] re: Attribute Selector example
Simon
I see that you meant function:node-match-1 in the example. I agree that it
is another way to specify the same policy. The difference in our opinions
would be relevant to how to handle XPath related function and data types in
XACML. In your example, you said that <AttributeSelector> can be translated
into 'function:xpath-expr' in Condition. If that is the case, what is the
return type of the xpath-expr function? It must be the same with the return
type of <AttributeSelector>, right? Besides, In line 821-830, string-equal
function receives a return value of the <AttributeSelector>. What data is
handed to the string-equal function?
Michiharu
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Simon Godik
<simon@godik.com> To: xacml@lists.oasis-open.org
cc:
2002/08/25 13:43 Subject: [xacml] re: Attribute Selector example
Michiharu,
I see that you want to compute the node-set of xpath expression specified
in
the request-context before passing it to the node-match function.
Of course, something like that could be accomplished in the condition
with 'xpath-expr' function:
<Apply FunctionId="function:node-match">
<Apply FunctionId="function:xpath-expr">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xs:string"/>
</Apply>
<AttributeSelector RequestContextPath="..."/>
</Apply>
You want to do the same thing in the target.
I'm not completely sold on your syntax for AttributeSelector. I'd prefer
this extension:
<AttributeSelector indirect="true"> (or IndirectAttributeSelector)
<ResourceAttributeDesignator AttributeId
="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xsi:string"/>
</AttributeSelector>
Better yet to relax 'match' element to allow 'apply' children.
Another approach:
I think that complication is in 'node-match' function definition that takes
--results--
of xpath expression. That forces you to produce this result, so you
need additional semantics in attribute-selector.
Consider different function that takes --xpath-expressions-- as arguments
(as in examples in section 3). Than you do not have to produce node sets
before calling this function and no change in schema is needed.
Suppose that node-match-1 has exact same semantics as node-match but
take 2 xpath expressions: xpath-expr-request and xpath-expr-rule:
node-match-1(xpath-expr-req, xpath-expr-rule).
You can use it in the target:
<ResourceMatch MatchId="function:node-match-1">
<ResourceAttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:xpath"
DataType="xsi:string"/>
<AttributeValue DataType="xsi:string">//md:record</AttributeValue>
</ResourceMatch>
Simon
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC