Re: [xacml] Paul's xpath proposal

[Erik Rissanen <erik@axiomatics.com>]

Hi Paul,

See inline.

On 2009-12-07 05:41, Tyson, Paul H wrote:
> Hi Erik,
>
> See inline.
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Monday, December 07, 2009 07:06
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: [xacml] Paul's xpath proposal
>>
>> Thanks Paul,
>>
>> Did you already update the wiki with the required cast? I
>> couldn't find it.
>>
>>      
> Are you seeing the latest at
> http://wiki.oasis-open.org/xacml/XpathDiscussion?
>
> In the example, I use count() in the RequestContextPath, which will
> return an integer that fn:boolean() will use to construct a boolean
> return value.
>    

Yes, I did see the count function. But I am uncertain that this will 
work. The XACML attribute selector requires a textual return value from 
the xpath expression. It is not defined in terms of the xs:boolean 
return value from the xpath expression. At least that is how I read the 
definition. Naturally, we could fix this and allow direct interpretation 
of xs:boolean.

>
>    
>> Another question. In the examples the xpath you are matching
>> against is always a single location step. Would it still work
>> with a path with multiple location steps? I get a feeling
>> that there will be a difference. Can you do it without an
>> absolute xpath anywhere? (Absolute xpaths cause problems for
>> optimization because the span the request context and may
>> also be a security risk since the<Request>  can be embedded
>> in a transport document.)
>>      
> I need to see some examples of this.  I can't picture it.
>    

I was thinking of wanting to check whether the resource-id (or 
content-selector in your examples) is within the subtree defined by 
md:record/md:patient_info. Your example is currently like this:

<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:boolean-equal">
<AttributeValue 
DataType="http://www.w3.org/2001/XMLSchema#boolean";>true</AttributeValue>
<AttributeSelector MustBePresent="false"
                      
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                      
RequestContextPath="count(ancestor-or-self::md:record)"
                      
ContextAttributeId="urn:oasis:names:tc:xacml:3.0:resource:content-selector"
                      
DataType="http://www.w3.org/2001/XMLSchema#boolean"; />
</Match>

This will first select the content-selector path and make the result of 
that the context node of the RequestContextPath. In this case the 
RequestContextPath tests whether it can find an ancestor element md:record.

But what if I want to see if I can find an ancestor 
md:record/md:patient_info? Just looking for md:patient_info would not do 
it, since that would also match md:foo/md:patient_info.

But, as I am writing this, I think I have the solution myself. The path 
could be "count(ancestor-or-self::md:patient_info/parent::md_record)".

Though, to prevent it from matching something which is deep in the 
<Content>, not directly at the <Content>, then it would need to be 
"count(ancestor-or-self::md:patient_info/parent::md_record)/parent::xacml:Content"


> I assume implementations will construct separate DOM objects for each
> Content element in the request, rather than try to apply xpath
> operations to a Request DOM.  If the implementation does the latter, it
> would have to "fix up" xpath expressions somehow, which could be tricky.
>    

I've been thinking about this in the past. It's an overhead to have to 
make a clone of the <Content> element, but not making a clone, does have 
it's risks. It allows climbing out of the <Content> element for instance.


>  From the policy writer's perspective, the request is just a wrapper for
> the Content, so his idea of absolute xpath expressions are those that
> begin at the root of<Content>.  (Maybe this is underspecified in XACML:
> since Content can contain multiple children, you must infer an anonymous
> "root" container for these children to correspond to a leading "/" in
> xpath.)
>    

I think xpath says that "/" refers to the document root element. In 
practice this could be <Content> if the implementation clones the 
<Content> element. It could be <Request>. Or it could be some wrappaing 
transport element such as SOAP.

>> Also, I am uncertain about the usabilitiy aspect. the xpath
>> node match functions are perhaps easier to understand than
>> clever xpath trickery. I am not sure yet where my opinion is
>> on that one. ;-)
>>      
> I guess we could leave them in as syntactic sugar, and define them in
> terms of native xpath.  For me (and probably for others with xslt
> experience), the XACML xpath-* functions are confusing.
>    

I think there will be users which think this is easier to understand:

(Allow access to anything under md:record/md:patient_info)

<Match MatchId="...:xpath-node-match">
<AttributeValue 
DataType="...:xpathExpression">md:record/md:patient_info</AttributeValue>
<AttributeDesignator MustBePresent="false"
               AttributeId="...:resource-id"
                      
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                      DataType="...:xpathExpression" />
</Match>

than this

<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:boolean-equal">
<AttributeValue 
DataType="http://www.w3.org/2001/XMLSchema#boolean";>true</AttributeValue>
<AttributeSelector MustBePresent="false"
                      
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                      
RequestContextPath="count(ancestor-or-self::md:patient_info/parent::md:record/parent::xacml:Content)"
                      ContextAttributeId="....:resource-id"
                      
DataType="http://www.w3.org/2001/XMLSchema#boolean"; />
</Match>

Best regards,
Erik