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
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