OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] [CR] AttributeSelectorIndirect



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? Does
that compare each of the return value of the attribute selector with "bb1"?

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?

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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC