MHonArc v2.5.2 -->
xacml message
[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