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
Yes, my impression is, once you agree to using general-string-equal (or
something similar), I think every rule that specifies AttributeSelector or
xpath-expr function must deal with object data type (or something similar).
Based on this observation, I don't think my original rule example using
node-match function has unnecessary complexity. Anyway, I agree that the
following syntax as you suggested is more consistent with the current
schema than the syntax I first proposed.
<ResourceMatch MatchId="function:node-match">
<AttributeSelectorIndirect>
<ResourceAttributeDesignator AttributeId="urn:...:resource:xpath"/>
</AttributeSelectorIndirect>
<AttributeSelector RequestContextPath="//md:record"/>
</ResourceMatch>
I changed the name to AttributeSelectorIndirect because I want
AttributeSelector at the head. I would prefer the above syntax to the
syntax below because I don't like to have many XPath expression parsing
functions (i.e. node-match-1 etc.) other than xpath-expr.
<ResourceMatch MatchId="function:node-match-1">
<ResourceAttributeDesignator AttributeId="urn:...:xpath"
DataType="xsi:string"/>
<AttributeValue DataType="xsi:string">//md:record</AttributeValue>
</ResourceMatch>
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/26 16:15 Subject: Re: [xacml] re: Attribute Selector example
Michiharu,
You are correct, xpath-expr return type is the same as attribute-selector,
which is a node-set. I was under impression that we have this function
defined.
I'm not sure what to do with string-equal receiving output of
attribute-selector.
May be the right thing to do is to use general-string-equal(object a,
object
b)
function that you proposed some time ago.
Simon
----- Original Message -----
From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
To: <xacml@lists.oasis-open.org>
Sent: Sunday, August 25, 2002 12:50 AM
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
>
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC