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] | [List Home]


Subject: Re: [xacml] New working drafts posted


Paul,

I am not convinced yet. :-)

XACML 2.0 has a specification which says that the xpath selects text 
content, which is then constructed into an XACML data type.

What you instead propose is that an XPath can select any XPath data 
type, and the return value of the xpath is directly the XACML value.

I see value for both approaches, but we cannot mix them in the same 
construct. This is what my code sample says. The same XPath gives two 
different XACML datatype end results depending which approach we use for 
the definition. We cannot mix them (at least not for any given XACML 
data type).

So this opens up the question about replacing the XACML 2.0 approach 
entirely with Paul's new proposal. It has the benefit that more clever 
things can be done with the xpath expression.

However, Paul's approach has the problem that not all XACML data types 
are available in XPath, or at least not in XPath 1. And definitely not 
in XPath 2 either if we consider that XACML is extensible so users could 
define arbitrary data types on their own. So to handle all XACML data 
types, including extensions, we need the "select string content" 
approach from XACML 2.0.

Another benefit with the old selector approach is that it easily handles 
selection of bags of attributes from the XML. I don't know how that 
would work in Paul's approach.

So I think the conclusion should be that we introduce a separate 
construct which is purely XPath based, which takes the XPath return 
value directly as the value of the XACML data type. For XPath 1 only 
string, boolean and integer will be possible return values. For XPath 2 
there will be many more.

And then I think there is ambiguity in the XACML 2.0 attribute selector 
definition as well. It's not clear to me what the "text representation" 
of an element node would be. For intance <Foo>true</Foo>, would the 
selector "peek" inside the element to get "true"? That seems 
inconsistent, if we imagine a custom extension data type type such as 
<Book><Author>Smith</Author><Title>A story</Title></Book>, where the 
book on the whole is treated a data type. There we would like to pass 
the entire <Book> node to the data type constructor, not peek inside.

Best regards,
Erik

P.S. My original email did not reach the list because of the broken 
roster yesterday, but Paul quoted it from his CC so you can find it below.



On 12/18/2009 04:25 PM, Tyson, Paul H wrote:
> Thanks for the code samples, Erik.
>
> As far as I can tell, the problem is limited to casting from text to
> boolean values.  I encountered this problem repeatedly in xslt 1.0
> processing, but I never determined whether the defect was in the
> specification or the implementations.  The problem has disappeared in
> xslt 2.0.
>
> The Java 5 xpath api is based on xpath 1.0, so it is not surprising to
> see this problem there as well.
>
> However, this is not a severe limitation.  It only causes ambiguity in
> the case where you want to distinguish between "does this node exist?"
> and "does this node have a lexical value corresponding to 'true' for the
> xsd:boolean datatype?"  The workaround requires the policy author to
> write xpath expressions that test the node value against the expected
> lexical values (e.g. "true","1", "yes", "false","0", "no") using the
> string equality operator.
>
> I modified Erik's sample to test numeric values, and it successfully
> evaluated "/ns:Foo/ns:Bar" with a numeric return value for
> "<ns:Bar>1</ns:Bar>".
>
> Therefore, I still believe we should allow any type of xpath expression
> in AttributeSelector/@Path, and specify that the result must be returned
> to the XACML environment as @DataType.  The rules for converting
> datatypes from xpath to XACML are well-defined.  Aside from the
> text-to-boolean problem noted above, this will in general be a useful
> and reliable way of testing XML content and structure.
>
> Regards,
> --Paul
>
>    
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Friday, December 18, 2009 03:41
>> To: Tyson, Paul H
>> Cc: xacml
>> Subject: Re: [xacml] New working drafts posted
>>
>> Paul, All,
>>
>> I wrote a small test program, and it is as I feared it would
>> be. There is a fundamental ambiguity between the modes
>>
>> 1. The XACML 2.0 model: "select text content and construct a
>> data type value from the text"
>>
>> 2. The model proposed by Paul: "evaluate an xpath and convert
>> the xpath return value data type into an xacml data type"
>>
>> These two cannot be combined in the same construct (the attribute
>> selector) without some extra XML attribute which
>> differentiates between them. If we want both, I propose we
>> separate them into say<AttributeSelector>  for the first and
>> <XPathExpression>  for the latter.
>>
>> The fundamental problem is that in the xpath world, an xpath
>> which matches a text node counts as "true", if seen as a
>> boolean, while XACML wants to look inside the text node to
>> see the value of the string content.
>>
>> Here is the java test program I wrote:
>>
>> package com.axiomatics.xpathtest;
>>
>> import java.io.StringReader;
>> import java.util.HashSet;
>> import java.util.Iterator;
>> import java.util.Set;
>>
>> import javax.xml.XMLConstants;
>> import javax.xml.namespace.NamespaceContext;
>> import javax.xml.parsers.DocumentBuilder;
>> import javax.xml.parsers.DocumentBuilderFactory;
>> import javax.xml.xpath.XPath;
>> import javax.xml.xpath.XPathConstants;
>> import javax.xml.xpath.XPathExpression;
>> import javax.xml.xpath.XPathFactory;
>>
>> import org.w3c.dom.Document;
>> import org.w3c.dom.NodeList;
>> import org.xml.sax.InputSource;
>>
>> public class Main2 {
>>
>>       static private class TestNamespaceContext implements
>> NamespaceContext {
>>
>>           static private final String myns = "http://example.com";;
>>           static private final String mypfx = "ns";
>>
>>           @Override
>>           public String getNamespaceURI(String prefix) {
>>               if(prefix.equals(mypfx)) {
>>                   return myns;
>>               } if(prefix.equals(XMLConstants.XML_NS_PREFIX)) {
>>               } else {
>>                   return XMLConstants.XML_NS_URI;
>>               } if(prefix.equals(XMLConstants.XMLNS_ATTRIBUTE)) {
>>                   return XMLConstants.XMLNS_ATTRIBUTE_NS_URI;
>>               } else {
>>                   return XMLConstants.NULL_NS_URI;
>>               }
>>           }
>>
>>           @Override
>>           public String getPrefix(String namespaceURI) {
>>               if(namespaceURI.equals(XMLConstants.XML_NS_URI)) {
>>                   return XMLConstants.XML_NS_PREFIX;
>>               } else
>> if(namespaceURI.equals(XMLConstants.XMLNS_ATTRIBUTE_NS_URI)) {
>>                   return XMLConstants.XMLNS_ATTRIBUTE;
>>               } else if(namespaceURI.equals(myns)) {
>>                   return mypfx;
>>               } else {
>>                   return null;
>>               }
>>           }
>>
>>           @Override
>>           public Iterator getPrefixes(String namespaceURI) {
>>               if(namespaceURI.equals(XMLConstants.XML_NS_URI)) {
>>                   Set result = new HashSet();
>>                   result.add(XMLConstants.XML_NS_PREFIX);
>>                   return result.iterator();
>>               } else
>> if(namespaceURI.equals(XMLConstants.XMLNS_ATTRIBUTE_NS_URI)) {
>>                   Set result = new HashSet();
>>                   result.add(XMLConstants.XMLNS_ATTRIBUTE);
>>                   return result.iterator();
>>               } else if(namespaceURI.equals(myns)) {
>>                   Set result = new HashSet();
>>                   result.add(mypfx);
>>                   return result.iterator();
>>               } else {
>>                   Set result = new HashSet();
>>                   return result.iterator();
>>               }
>>           }
>>       }
>>
>>       private static final String xmlText =
>>           "<ns:Foo xmlns:ns=\"http://example.com\";>\n" +
>>           "<ns:Bar>false</ns:Bar>\n" +
>>           "</ns:Foo>\n";
>>
>>       static public void main(String[] args) throws Exception {
>>           DocumentBuilderFactory dbfact =
>> DocumentBuilderFactory.newInstance();
>>           dbfact.setNamespaceAware(true);
>>           DocumentBuilder db = dbfact.newDocumentBuilder();
>>
>>           Document indoc = db.parse(new InputSource(new
>> StringReader(xmlText)));
>>
>>           // According to XACML 2.0 spec this if requested for
>> an XACML boolean
>>           // should return "false" since it selects text
>> content with the string "false".
>>           String xpathStr = "/ns:Foo/ns:Bar/text()";
>>
>>           // compile the expression
>>           XPathFactory factory = XPathFactory.newInstance();
>>           XPath xpath = factory.newXPath();
>>           xpath.setNamespaceContext(new TestNamespaceContext());
>>           XPathExpression xPathEx = xpath.compile(xpathStr);
>>
>>           // Match it as a nodeset. An XACML 2.0 implementation
>>           // would take the text content and construct a
>>           // an XACML boolean from the text value.
>>           NodeList nodelist = (NodeList)
>> xPathEx.evaluate(indoc.getDocumentElement(),
>>                   XPathConstants.NODESET);
>>           System.out.println("Matching nodes are: ");
>>           for(int i = 0; i<  nodelist.getLength(); i++) {
>>               System.out.println("  ->  " +
>> nodelist.item(i).toString());
>>           }
>>
>>           // Try to get the value directly using the same data type as
>>           // the attribute selector data type, that is, a boolean.
>>           // This will return "true", which is different from above.
>>           Boolean bool = (Boolean) xPathEx.evaluate(indoc,
>> XPathConstants.BOOLEAN);
>>           System.out.println("Return value is: " + bool);
>>       }
>> }
>>
>> Best regards,
>> Erik
>>
>>
>>
>> On 2009-12-17 20:22, Erik Rissanen wrote:
>>      
>>> See inline,
>>>
>>> On 12/17/2009 06:55 PM, Tyson, Paul H wrote:
>>>        
>>>>>> 2. Lines 2458/2461 unnecessarily restrict the @Path xpath
>>>>>>              
>>>>> expressions
>>>>>            
>>>>>> to those that select nodes from an XML document.  It
>>>>>>              
>> would exclude
>>      
>>>>>> node comparisons, counting, positional queries, and other useful
>>>>>> expressions for testing XML structure.  Erik thought
>>>>>>              
>> this would be
>>      
>>>>>> difficult to implement because of ambiguous return types
>>>>>>              
>> from these
>>      
>>>>>> expressions, but in fact they will be better-defined than
>>>>>>              
>>>>> XML nodes,
>>>>>            
>>>>>> which will appear as string values when put into the XACML
>>>>>>              
>>>>> context.
>>>>>            
>>>>>> The @DataType attribute of AttributeSelector will control
>>>>>>              
>>>>> the return
>>>>>            
>>>>>> type to the XACML context, and if this type cannot be
>>>>>>              
>>>>> constructed from
>>>>>            
>>>>>> the return value of the xpath expression the application
>>>>>>              
>>>>> must signal
>>>>>            
>>>>>> an error.  But this will not be the common case, and
>>>>>>              
>> when it does
>>      
>>>>>> arise the policy author can adjust the xpath expression
>>>>>>              
>> to cast the
>>      
>>>>>> value to a suitable argument type for the constructor
>>>>>>              
>>>>> function.  As I
>>>>>            
>>>>>> suggested earlier, this paragraph should be replaced with:
>>>>>>
>>>>>>              
>>>>> I tried to explain earlier that it is not as simple as that the
>>>>> @Datatype of the attribute selector can control this.
>>>>> Let's assume that I implement the selector with the Java
>>>>>            
>> XPath API.
>>      
>>>>> The method for evaluating an xpath looks like this:
>>>>>
>>>>> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/xpath/XPathE
>>>>> xpression.html#evaluate%28org.xml.sax.InputSource,%20javax.xml
>>>>>            
>>>> .namespace.QName%29
>>>>          
>>>>> Object evaluate(InputSource source, QName returnType)
>>>>>                    throws XPathExpressionException
>>>>>
>>>>> I have to specify the return type of the xpath expression when I
>>>>> evaluate it. This is not the same thing as the return type of the
>>>>> attribute selector, which the @Datatype denotes.
>>>>>            
>>>> There is also an evaluate() method without the return type, so the
>>>> client application could sort out the datatype if it wanted to.
>>>>          
>>> Do you refer to
>>>
>>>   String evaluate(InputSource source)
>>>
>>> This is just a shorthand for evaluate(source, XPathConstants.STRING)
>>>
>>>
>>>
>>>        
>>>>> Consider this example:
>>>>>
>>>>> <Content>
>>>>> <Foo>true<Foo>
>>>>> </Content>
>>>>>
>>>>> <AttributeSelector Datatype="...boolean" Path="Foo/text()">
>>>>>
>>>>> then the xpath expression will evaluate to the string
>>>>>            
>> "true", which
>>      
>>>>> according to the XACML spec has to be cast into an XACML
>>>>>            
>> boolean. I
>>      
>>>>> must invoke the xpath evaluation with:
>>>>>
>>>>> evaluate(source, XPathConstants.STRING)
>>>>>            
>>>> The question is, does the the xpath implementation try to cast the
>>>> results to the desired type?  I would assume so, in which case you
>>>> can use the AttributeSelector/@DataType as the return type.
>>>>          
>>> Yes, maybe so. When I re-read it now, it appears so. The
>>>        
>> first time I
>>      
>>> read it, I had the impression that this was not the case.
>>>        
>> I'll try it
>>      
>>> out later.
>>>
>>>        
>>>>> However, look at this:
>>>>>
>>>>> <AttributeSelector Datatype="...boolean"
>>>>>            
>> Path="self::node() = Foo">
>>      
>>>>> In this case the data type of the selector is still an
>>>>>            
>> XACML boolean.
>>      
>>>>> The difference is that the xpath expression returns an XPath
>>>>> boolean, which means I have to evaluate it with:
>>>>>
>>>>> evaluate(source, XPathConstants.BOOLEAN)
>>>>>
>>>>> If the implementation uses the wrong form, the XPath API
>>>>>            
>> will throw
>>      
>>>>> an exception.
>>>>>            
>>>> The XACML application cannot go wrong by using the @DataType value
>>>> everywhere.
>>>>          
>>> Maybe. I need to check this, but now that I read the API
>>>        
>> once more, I
>>      
>>> think you are right. Though, we can't use the @Datatyp
>>>        
>> directly since
>>      
>>> XACML has more data types than XPath (at least XPath 1). And XACML
>>> uses URIs, which need to be converted to QNames. Anyway,
>>>        
>> that should
>>      
>>> be workable.
>>>
>>>        
>>>>> I don't know whether we should consider this a flaw in the java
>>>>> XPath API, or a more fundamental type checking issue, but
>>>>>            
>> in either
>>      
>>>>> case it is a practical difficulty for implementation. We
>>>>>            
>> could add a
>>      
>>>>> @PathReturnType attribute to the selector, and then the
>>>>> implementation would know. Any other suggestion?
>>>>>            
>>>> I'm not in favor of an additional attribute.  If the
>>>>          
>> underlying xpath
>>      
>>>> api or implementation has problems, then it will throw nuisance
>>>> errors and will perhaps be unusable.  But that should not
>>>>          
>> affect or
>>      
>>>> restrict how we write XACML policies and make XACML requests.
>>>>
>>>> The bigger problem might be how to get a sequence of
>>>>          
>> values, without
>>      
>>>> knowing in advance whether an xpath expression will return one or
>>>> several values.  The most useful API would always return a
>>>>          
>> sequence
>>      
>>>> from evaluate().
>>>>          
>>> This could be a problem with the java xpath API. It differentiates
>>> between NODE and NODESET as return types, but with some
>>>        
>> luck one can
>>      
>>> always use NODESET and get a singleton set in case there is
>>>        
>> a single
>>      
>>> node.
>>>
>>>        
>>>>>
>>>>>            
>>>>>> === proposed wd14 lines 2458/2461 === If the XPath expression
>>>>>> selects a sequence of XML nodes (text, attribute, element,
>>>>>> processing instruction, or comment nodes), then the string
>>>>>> representation of the value of each node MUST be
>>>>>>              
>>>>> converted
>>>>>            
>>>>>> to an attribute value of the specified data-type, and
>>>>>>              
>> the result of
>>      
>>>>>> the AttributeSelector is the bag of the attribute values
>>>>>>              
>> generated
>>      
>>>>>> from all the selected nodes.
>>>>>> =====================================
>>>>>>
>>>>>> 3. Lines 2466/2469 regarding the definition of the XML
>>>>>>              
>>>>> infoset that is
>>>>>            
>>>>>> subject to xpath processing:  The xacml:Content element does not
>>>>>> belong in this infoset.  The XML that is subject to xpath
>>>>>>              
>>>>> evaluation
>>>>>            
>>>>>> should be the sequence of nodes that are the children of the
>>>>>> xacml:Content element.  This can include zero or more elements,
>>>>>> comments, processing instructions, and text nodes.  I propose
>>>>>> replacing the first sentence of this paragraph with:
>>>>>>
>>>>>> === proposed wd14 lines 2466/2467 === The Xpath
>>>>>>              
>> expression MUST be
>>      
>>>>>> evaluated in a context which is equivalent to a node sequence
>>>>>> formed of all the child nodes of the<Content>   element,
>>>>>>              
>> and all the
>>      
>>>>>> attributes and
>>>>>>              
>>>>> descendants of those nodes.
>>>>>            
>>>>>> Namespace declarations ... [unchanged]
>>>>>> ======================================
>>>>>>
>>>>>> Note that this makes user-defined attributes of xacml:Content
>>>>>> invisible to xpath expressions, so we should consider removing
>>>>>> "anyAttribute" from the schema definition of xacml:Content.
>>>>>>
>>>>>>              
>>>>> I think we want the<Content>   element since otherwise
>>>>>            
>> it's not going
>>      
>>>>> to be a valid stand alone XML document. (XML requires a single
>>>>> document element, righ?) If there is not a single
>>>>>            
>> document element,
>>      
>>>>> the aboslute xpath "/" becomes undefined. There is no harm having
>>>>> the content element there.
>>>>> In fact, it could even be beneficial to use the XML attributes of
>>>>> the<Content>   element since XML attributes have a slightly more
>>>>> compact encoding form than elements (which repeat the name of the
>>>>> element at the end tag).
>>>>>
>>>>>            
>>>> I think that xacml:Content belongs in the XACML world, and its
>>>> children belong in the user's world.  The<Content>   element is a
>>>> wrapper that should not be visible or accessible during
>>>>          
>> policy evaluation.
>>      
>>>> We should define this in terms of the xpath data model
>>>>          
>> (XDM) instance
>>      
>>>> that will be created from xacml:Content, which will be the
>>>>          
>> subject of
>>      
>>>> any xpath expression evaluations.  The "sequence of nodes" I
>>>> originally proposed will not work.  I propose the model be
>>>>          
>> specified as:
>>      
>>>> 1. A new document node will be created for each<Content>   element.
>>>> 2. All xml content of the xacml:Content element will be parsed and
>>>> put into the xpath data model as specified by the xpath data model
>>>> specification (http://www.w3.org/TR/xpath-datamodel).
>>>>
>>>> (This is a notional specification only--there is no
>>>>          
>> requirement that
>>      
>>>> the implementation actually do this--only that the results
>>>>          
>> of xpath
>>      
>>>> evaluation are the same as if this had been done.)
>>>>
>>>> Note that this could result in a valid XDM structure that would be
>>>> malformed XML, because the document node could have
>>>>          
>> several element
>>      
>>>> children. (In an XDM constructed from valid XML, the document node
>>>> would have only one element child--the document element.)
>>>>          
>> I do not
>>      
>>>> see anything that prohibits this, either in the XDM or the Xpath
>>>> specification.
>>>>          
>>> Yes, the content belongs to the XACML world, but I think it is
>>> perfectly fine as a place holder. A policy belongs to the
>>>        
>> XACML world
>>      
>>> and having a content element as the starting point of expressions
>>> seems fine for me.
>>>
>>> I am not sure if I understand what you propose. The data
>>>        
>> model is part
>>      
>>> of XPath 2.0. Will your approach work with 1.0?
>>>
>>>  From my experience about using the java xpath API, it
>>>        
>> requires a DOM
>>      
>>> and absolute xpaths don't work correctly if the document element of
>>> the DOM is not set. I see in the spec for the XPath data
>>>        
>> model that a
>>      
>>> document node is not required to contain exactly one element child,
>>> but what would "/" resolve to in your approach?
>>>
>>> Best regards,
>>> Erik
>>>
>>>
>>>        
>>
>>      



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