OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] [CR] AttributeSelectorIndirect

  • 1.  Re: [xacml] [CR] AttributeSelectorIndirect

    Posted 09-04-2002 10:01
     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


    
    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"
    
    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"
    
    Case C:
    XPath expression of "/a/b/c/text()" returns a text node:
    text node that contains "xyz"
    
    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)
    
    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. (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>
    
    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>
    >
    
    
    
    
    
    
    


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


    Powered by eList eXpress LLC