[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] [CR] AttributeSelectorIndirect
On Sat, 7 Sep 2002, Michiharu Kudoh wrote: > > Polar > > >This example is wrong. The second element of a ResourceMatch must be a > >primitive value, currently an explicit AttributeValue. > > OK. I agree that the target expression should be simple only allowing a > primitive type as a second element. Suppose the following policy: > > <a a1="aaa"> > <b b1="200"> > <c>bb1</c> > <c>bb2</c> > </b> > <b b1="100"/> > </a> > > <ResourceMatch MatchId="function:string-equal"> > <AttributeSelector RequestContextPath="/a/b/c/text()"> > <AttributeValue>bb1</AttributeValue> > </ResourceMatch> > > The first attribute selector may return a sequence of primitive types (e.g. > bb1 and bb2). Then what is the semantics of the function:string-equal? Well we haven't gotten that specified, but I belive what ever the XML Schema says about "equality" of strings. > Does that compare each of the return value of the attribute selector > with "bb1"? Yes. > What if function:integer-equal is used? > > <ResourceMatch MatchId="function:integer-equal"> > <AttributeSelector RequestContextPath="/a/b/@b1"> > <AttributeValue>100</AttributeValue> > </ResourceMatch> > > Comparison is done based on numeric comparison? Yes. -Polar > 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 <xacml@lists.oasis-open.org> > 2002/09/06 22:14 Subject: Re: [xacml] [CR] AttributeSelectorIndirect > > > > > > > > Hi Michiharu, > > Comments are inline. > > On Fri, 6 Sep 2002, Michiharu Kudoh wrote: > > > > > Polar > > > > I have a couple questions. > > > > 1. How to mandate a returned data from the attribute selector to be a > > sequence of a specific type? Are you suggesting to specify DataType > > attribute in the attribute selector element? > > You always must apply a function to any result of an attribute selector. > That function specifies the types of its formal parameters, and therefore > implies the type of the attribute selector. You said so yourself for > AttributeValues. > > > 2. I am not clear on how to specify resource match using > > function:string-equal. Is the following policy fragment correct if the > > attribute selector returns a sequence of a primitive type (string type > > because function:string-equal implies that)? > > > > <ResourceMatch MatchId="function:string-equal"> > > <AttributeSelector RequestContextPath="/a/b/@b1/"> > > <AttributeSelector RequestContextPath="/a/b/c/text()"/> > > </ResourceMatch> > > This example is wrong. The second element of a ResourceMatch must be a > primitive value, currently an explicit AttributeValue. > > <ResourceMatch MatchId="function:string-equal"> > <AttributeSelector RequestContextPath="/a/b/@b1/"> > <AttributeValue>bb1</AttributeValue> > </ResourceMatch> > > However, if you really want to put a "value" as the second argument, of > which I cannot see a good argument against, it would require a SCHEMA > CHANGE. > > Given that we agree with that, If you believe the /a/b/c/text() will > return a sequence of one you would use: > > <ResourceMatch MatchId="function:string-equal"> > <AttributeSelector RequestContextPath="/a/b/@b1/"> > <Apply FunctionId="string-first-and-only"> > <AttributeSelector > RequestContextPath="/a/b/c/text()"/> > </Apply> > </ResourceMatch> > > If for some reason, your resource data model is screwed up, and your > "/a/b/c/text()" attribute selector returns a sequence of more than one or > empty, you will get an Indeterminate (i.e. an error). > > > 3. I want to see specification examples how to use each function in Match > > element and Condition element. > > Above is one example. > > > Sample XACML Contexts and policy specifications would be helpful to > > understand how to use functions. Otherwise, I cannot have a clear > > mapping between XPath 1.0 (and 2.0) functions and XACML functions. > > Is the above enough to get the point across? > > -Polar > > > 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 > <xacml@lists.oasis-open.org> > > 2002/09/05 23:01 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> > > > > > > > > > ---------------------------------------------------------------- > > 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