Re: AW: [xacml] Category vs XPathCategory

[Erik Rissanen <erik@axiomatics.com>]

Hi Jan,

1. There is an open issue for "fixing" the attribute selector. I think 
it's issue #11, but I didn't check now, so I could be wrong. I'm not 
sure if the solution is as simple as you say. For instance, how does one 
define a concatenation operation for xpaths? Think about namespace 
prefix collisions for instance. An offset which selects a context node 
for the second xpath seems simpler. We need to do more work on that issue.

2. The reason is that many things in the implementation become 
inefficient if an xpath expression can span the whole request or across 
categories.

For instance that a full XML document must be constructed for the whole 
individual request in case of "repeated <Attributes> elements". If the 
xpath expression is contained withing a single <Content> element, then 
the XML document of the original request can be "reused" for each 
individual request.

Another example is that dynamic/lazy lookup of attributes by the context 
handler on demand through policy evaluation becomes very difficult to 
implement if an XPath expression can span the whole request. Since an 
attribute selector could be used to refer to the <Attributes> elements 
in the request, in effect, the context handler must resolve all 
potentially reachable attributes from all sources and construct an XML 
document with them before any xpath expression can be evaluated. If the 
implementation would not do that, there would be subtle differences in 
how attributes behave: selector vs designator, provided by PEP vs found 
by context handler, etc, which could cause all kinds of problems and 
security issues.

Best regards,
Erik


Jan Herrmann wrote:
> Hi Erik,
>
> thanks for this clear presentation of the issue.
> If I may add two remarks/questions:
>
> 1:
> If the AttributeSelector would have it's RequestContextPath Attribute as
> Child element, this sort of special treatment (i.e. the Category Attribute
> within the AttributeSelector) could be avoided. 
> You could simply use the <AttributeValue> approach:
> e.g.:
> <AttributeSelector xmlns:si="http://example.com/subject-inf";
> MustBePresent="true" DataType="http://www.w3.org/2001/XMLSchema#string";>
>   <AttributeValue
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> xmlns:si="http://example.com/subject-inf";>
>     si:SubjectInfo/si:Clearance/text()
>   </AttributeValue>
> </AttributeSelector>
>
> Such an approach will unify the both cases. Further this will allow for many
> other things (think e.g. of the discussion on Selector(condad(resource-id,
> /anyOffset))
>
> 2:
> out of curiosity. What is the advantage to split the semantic of the
> selector's pointer in two parts?
> Currently the source nodes are identified by:
> a) the Category Attribute (sets the context node) and 
> b) the xpath expression under the RequestContextPath Attribute 
> Why is the context node not always the root node of the decision request
> i.e. /Request?
>
>
> Best regards
> jan
> PS: I have pretty busy times at the moment so I didn't have time yet to
> review your proposal on the "running XPath in reverse" approach. I will try
> to follow your thoughts asap.
>
>
>
>
>
>
> ________________________________________
>
> Jan Herrmann
> Dipl.-Inform., Dipl.-Geogr. 
>
> wissenschaftlicher Mitarbeiter
>
> Technische Universität München
> Institut für Informatik 
>
> Lehrstuhl für Angewandte Informatik / Kooperative Systeme
>
> Boltzmannstr. 3
> 85748 Garching
>
> Tel:      +49 (0)89 289-18692
> Fax:     +49 (0)89 289-18657
> www11.informatik.tu-muenchen.de
> ________________________________________
>  
>
>   
>> -----Ursprüngliche Nachricht-----
>> Von: Erik Rissanen [mailto:erik@axiomatics.com]
>> Gesendet: Donnerstag, 29. Oktober 2009 16:47
>> An: XACML TC
>> Betreff: [xacml] Category vs XPathCategory
>>
>> All,
>>
>> During the call today, I promised to post an explanation between the
>> "Category" and "XPathCategory" XML attributes. Both attributes are used
>> to indicate the context node of an xpath expression. The difference is
>> that in XACML there are two ways in which an XPath expression can occur:
>> in an <AttributeSelector> or in the new xpathExpression data type. The
>> two attributes go with the two different ways. The details are below.
>>
>> "Category" is an attribute of <AttributeSelector>
>>
>>     <xs:element name="AttributeSelector"
>> type="xacml:AttributeSelectorType" substitutionGroup="xacml:Expression"/>
>>     <xs:complexType name="AttributeSelectorType">
>>         <xs:complexContent>
>>             <xs:extension base="xacml:ExpressionType">
>>                 <xs:attribute name="Category" type="xs:anyURI"
>> use="required"/>
>>                 <xs:attribute name="RequestContextPath" type="xs:string"
>> use="required"/>
>>                 <xs:attribute name="DataType" type="xs:anyURI"
>> use="required"/>
>>                 <xs:attribute name="MustBePresent" type="xs:boolean"
>> use="required"/>
>>             </xs:extension>
>>         </xs:complexContent>
>>     </xs:complexType>
>>
>> This attribute is used to define which <Content> element is the context
>> node of the xpath expression in the selector.
>>
>> Here is an example of an attribute selector:
>>
>> <Match
>>   MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>>   <AttributeValue
>>     DataType="http://www.w3.org/2001/XMLSchema#string";>A</AttributeValue>
>>     <AttributeSelector
>>       xmlns:si="http://example.com/subject-inf";
>>
>> Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
>>       RequestContextPath="si:SubjectInfo/si:Clearance/text()"
>>       MustBePresent="true"
>>       DataType="http://www.w3.org/2001/XMLSchema#string"/>
>>
>> The above match will test whether the si:SubjectInfo/si:Clearance
>> element in the subject <Content> element contains the string value "A".
>>
>> XPathCategory is an attribute of an <AttributeValue> which contains an
>> xpath expression value.
>>
>>     <xs:element name="AttributeValue" type="xacml:AttributeValueType"
>> substitutionGroup="xacml:Expression"/>
>>     <xs:complexType name="AttributeValueType" mixed="true">
>>         <xs:complexContent mixed="true">
>>             <xs:extension base="xacml:ExpressionType">
>>                 <xs:sequence>
>>                     <xs:any namespace="##any" processContents="lax"
>> minOccurs="0" maxOccurs="unbounded"/>
>>                 </xs:sequence>
>>                 <xs:attribute name="DataType" type="xs:anyURI"
>> use="required"/>
>>                 <xs:anyAttribute namespace="##any" processContents="lax"/>
>>             </xs:extension>
>>         </xs:complexContent>
>>     </xs:complexType>
>>
>> Notice how the <AttributeValue> can contain any XML attributes or any
>> content for encoding of data type values. The 3.0 xpath expression data
>> type is the only standard XACML datatype which uses an XML attribute to
>> encode part of its value. The XPathCategory defines the category of the
>> <Content> element which is the context node for the xpath expression in
>> the <AttributeValue> element.
>>
>> Here is an example of an xpath expression data type value:
>>
>> <Match
>>   MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">
>>   <AttributeValue
>>     DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
>>
>> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
>>     md:record/md:patient_info/md:name
>>   </AttributeValue>
>>   <AttributeDesignator
>>     Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
>>     AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
>>     DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>
>> </Match>
>>
>> The above expression will test whether the resource id is an xpath
>> expression which points within the subtree under
>> md:record/md:patient_info/md:name in the resource category <Content>
>> element.
>>
>> Best regards,
>> Erik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>     
>
>