[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] [CR] AttributeSelectorIndirect
Michiharu, Comments inline. On Wed, 4 Sep 2002, Michiharu Kudoh wrote: > > Hi, Polar > > I think that the policy syntax I posted before can be consistent with the > functions and data types specified in the latest draft of XACML standard > function. (when I first proposed, there was no notion of sequence data > type) Since XACML supports a sequence and a set data types, functions that > processes XPath expressions can be mapped to those data types. > > Basically XPath 1.0 defines a return type as an object data type > (either node-set, boolean, number, or string). To define a mapping > rule from XPath object data type to XACML sequence data type would be > a choice, I think. The problem would be that "node-set" of XPath is > different from "sequences of primitive types". It is not a sequence of > primitive-type data but just a set of (DOM) nodes which may include a > structured node. But if we ignore that structured node case, it would > be easy to map node-set to "sequence of primitive type". Then the > definition of <AttributeSelector> processes XPath expressions and do a > data conversion. Examples are the following: > > Suppose there is a XML document: > <a a1="aaa"> > <b b1="bb1"> > <c>bb1</c> > </b> > <b b1="bb2"/> > </a> > > Case A: > XPath expression of "/a/@a1" returns an attribute node: > attribute node "a1" that contains a text node "aaa" I believe we mandate this to be a sequence of a specific type implied by the function applied to it. Such as if we used "function:string-member-of" on this result of this XPATH expression its type is implied to be a sequence of xs:string, for XACML purposes. > Case B: > XPath expression of "/a/b/@b1" returns two attribute nodes "b1": > attribute node "b1" that contains "bb1" > attribute node "b1" that contains "bb2" Again, I believe we mandate this to be a sequence of a specific type implied by the function applied to it. If we used "function:string-memeber-of" it would be considered a sequence of xs:string containing "bb1" and "bb2". > Case C: > XPath expression of "/a/b/c/text()" returns a text node: > text node that contains "xyz" again, same thing. > Above three cases indicates a natural mapping from node set to a sequence > of primitive data types. (For simplicity, I ignore primitive data type > here) I agree. > Case D: > XPath expression of "/a/b" returns two notes: > element node "b" that contains element "c" and attribute "b1" > element node "b" that contains attribute "b1" > > In Case D, there is no natural mapping from returned node set because > returned object is a structured node. (In XPath 1.0, there is a conversion > definition of structured node (as a string value), I don't think it fits to > XACML case.) > > One possibility would be to raise an error for Case D, or returns an empty > sequence without error. I think returning and empty sequence is a REALLY bad idea. If we allowed this kind of thing, there is no need for a type system or any integrity to the evaluation of policy against its inputs. If you have a node-set that is some type other than the standard types that we support, you should use create a type extension and functions that explicity know how to deal with that extension, otherwise it is an error (which can quite possibly be handled at compile time). > (Anyway, policy writer must be sure that the XPath > expression really returns sequence of primitive types.) > Based on the above observation, the following example returns true: > > <ResourceMatch MatchId="function:has-string-intersection"> > <AttributeSelector RequestContextPath="/a/b/@b1/"> > <AttributeSelector RequestContextPath="/a/b/c/text()"/> > </ResourceMatch> I thinkthe function you would use here would be "function:string-equal" because the ResourceMatch has the semantics of applying the function named by MatchId to the elements in the sequences to see if there is a match. -Polar > For example, function:has-intersection returns true because the first > argument and the second argument has an intersection ("bb1") as a string > value. > > Michiharu > > IBM Tokyo Research Laboratory, Internet Technology > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 > > > > > > Polar Humenn > <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP > cc: XACML <xacml@lists.oasis-open.org> > 2002/08/30 21:47 Subject: Re: [xacml] [CR] AttributeSelectorIndirect > > > > > > > > Michiharu, > > Comments inline. > > On Fri, 30 Aug 2002, Michiharu Kudoh wrote: > > > > > Line 804-810 of draft 0.16e, there is a resource match in Example 2 Rule > 1: > > > > <ResourceMatch MatchId="function:node-match"> > > <ResourceAttributeDesignator AttributeId="urn:...:xpath" > > DataType="xsi:string"/> > > <AttributeValue DataType="xsi:string">/md:record</AttributeValue> > > </ResourceMatch> > > > > In the above example, the node-match function is defined as > > > > Function: node-match > > input: xs:string, xs:string > > output: xs:boolean > > description: receive two xpath expressions and executes xpath processor > on > > both xpaths. It generates two objects (object type is defined in XPath > 1.0, > > i.e. node-set, string, numeric, or boolean). When two objects have an > > intersection, then it returns true, otherwise return false. > > This function, although a little unwieldy, is fine, provided you can > provide a deterministic definition for a node-match. ("when two object > have an intersection") is somewhat lacking. > > > Instead of the above node-match function and the resource match > > specification, I would prefer the definition and resource match > > specification using <AttributeSelectorIndirect> below: > > > > Function: node-match > > input: object, object > > output: xs:boolean > > description: receive two objects. When two node-sets have an > intersection, > > then it returns true, otherwise return false. > > > > <ResourceMatch MatchId="function:node-match"> > > <AttributeSelectorIndirect> > > <ResourceAttributeDesignator AttributeId="urn:...:xpath"/> > > </AttributeSelectorIndirect> > > <AttributeSelector RequestContextPath="/md:record"/> > > </ResourceMatch> > > Why? > > Your previous approach is fine, and works within our type system. It takes > two arguments of primitive types ("xs:string") and returns an xs:boolean. > > This approach requires "node-match" to be polymorphic and for XACML > processors to understand abstract data types. Our simple type system > cannot support it. We would now have much more than primitive types, and > sequences of primitive types. We would have abstract data types (i.e. > arbitrary XML nodes) introduced into the type system. > > Also, in this case, you must note that the selectors must contain the > "DataType" attribute to make type sense out of their results, as these > selectors can end up in other function applications. I think we are > trying to get rid of the DataType attribute, because of the type > inference. > > Also, I think you left the "DataType" attribute out in this example, for > obvious reasons. You don't know what legal value to give it. > > In both cases, however, you still need to come up with an explicit > specification of for the function "node-match". > > If you can come up with a specification of node-match, I would strongly > prefer that it was a function that fit with our type system, i.e. your > first example, which takes two XPATH expressions and returns a boolean. > > > > Other example (not AttributeSelectorIndirect but AttributeSelector case) > is > > line 825-835. The function:string-equal should be the > > function:general-string-equal because <AttributeSelector> returns an > object > > data type (maybe node-set) and it is not proper to hand it to > string-equal > > function. > > I don't even have a specification for "string-equal", let alone > "general-string-equal", so I don't really understand the difference. > > Cheers, > -Polar > > > <Condition FunctionId="function:string-equal"> > > <SubjectAttributeDesignatorWhere > > AttributeId="urn:...:policy-number" DataType="xsi:string"/> > > <AttributeSelector RequestContextPath="/ctx:Request/ ... > > /md:policyNumber" > > DataType="xsi:string"/> > > </Condition> > > > > [should be] > > > > <Condition FunctionId="function:general-string-equal"> > > <SubjectAttributeDesignatorWhere > > AttributeId="urn:...:policy-number" DataType="xsi:string"/> > > <AttributeSelector RequestContextPath="/ctx:Request/ ... > > /md:policyNumber" > > DataType="xsi:string"/> > > </Condition> > > > > Michiharu Kudo > > > > IBM Tokyo Research Laboratory, Internet Technology > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 > > > > > > > > > > > > Polar Humenn > > <polar@syr.edu> To: Michiharu > Kudoh/Japan/IBM@IBMJP > > cc: > <xacml@lists.oasis-open.org> > > 2002/08/30 03:27 Subject: Re: [xacml] [CR] > AttributeSelectorIndirect > > > > > > > > > > > > > > > > > > Michiharu, > > > > Is there a use case or example for this type of attribute selector? > > > > Cheers, > > -Polar > > > > On Thu, 29 Aug 2002, Michiharu Kudoh wrote: > > > > > Based on the discussion on Monday call, Simon and I agreed to changing > > the > > > schema to support an AttributeSelectorIndirect element to retrieve a > > XPath > > > expression from the context. I wonder whether the name of this element > is > > > appropriate or not. > > > > > > <xs:complexType name="AttributeSelectorBaseType"> > > > <xs:element ref="xacml:XPathNamespace" minOccurs="0" maxOccurs > > > ="unbounded"/> > > > <xs:attribute name="DataType" type="xs:anyURI" use="optional"/> > > > <xs:attribute name="XPathVersion" type="xs:anyURI" use="optional" > > default > > > ="http://www.w3.org/TR/1999/Rec-xpath-19991116"/> > > > </xs:complexType> > > > > > > <xs:complexType name="AttributeSelectorType"> > > > <xs:complexContent> > > > <xs:extension base="AttributeSelectorBaseType"> > > > <xs:attribute name="RequestContextPath" type="xs:string" use > > > ="required"/> > > > </xs:extension> > > > </xs:complexContent> > > > </xs:complexType> > > > > > > <xs:complexType name="AttributeSelectorIndirectType"> > > > <xs:extension base="AttributeSelectorBaseType"> > > > <xs:choice> > > > <xs:element ref="xacml:SubjectAttributeDesignator"/> > > > <xs:element ref="xacml:ResourceAttributeDesignator"/> > > > <xs:element ref="xacml:ActionAttributeDesignator"/> > > > <xs:element ref="xacml:EnvironmentAttributeDesignator"/> > > > </xs:choice> > > > </xs:extension> > > > </xs:complexType> > > > > > > <xs:element name="AttributeSelector" type="AttributeSelectorType"/> > > > <xs:element name="AttributeSelectorIndirect" type > > > ="AttributeSelectorIndirectType"/> > > > > > > <xs:element name="XPathNamespace" type="xacml:XPathNamespaceType" > > > substitutionGroup="xacml:AbstractDefaults"/> > > > <xs:complexType name="XPathNamespaceType"> > > > <xs:attribute name="NamespaceURI" type="xs:anyURI"/> > > > <xs:attribute name="Prefix" type="xs:string" use="optional"/> > > > </xs:complexType> > > > > > > > > > Sample text for this element: > > > > > > 5.28. Element <AttributeSelectorIndirect> > > > > > > The <AttributeSelectorIndirect> element is a free-form pointing device > > into > > > the <xacml-context:Request> element using an attribute designator. The > > > actual xpath expression is retrieved from the context pointed by that > > > attribute designator. Other than that, the semantics is the same with > > > <AttributeSelector> element. Support for the > <AttributeSelectorIndirect> > > > element is OPTIONAL. > > > > > > The <AttributeSelectorIndirect> element is of > > AttributeSelectorIndirectType > > > complex type. > > > The <AttributeSelectorIndirect> element has either one of the following > > > elements: > > > > > > SubjectAttributeDesignator > > > ResourceAttributeDesignator > > > ActionAttributeDesignator > > > EnvironmentAttributeDesignator > > > > > > Michiharu > > > > > > IBM Tokyo Research Laboratory, Internet Technology > > > Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > > > 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> > > > > > > > > > > ---------------------------------------------------------------- > 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