[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