OASIS eXtensible Access Control Markup Language (XACML) TC

All,


(I am mailing this in HTML since some of the lines are long, and I
don't want them to be cut off. I hope this works.)


One issue which was brought up several times during the TC call
yesterday was that some TC members said that the multiple resource
profile does not define in any normative manner how the XPath based
multiple request is divided into individual requests. I don't agree, so
here is a walkthrough of an example with references to the
specification.


The relevant section is 2.2 of the multiple resource profile. I am
using the PDF version of the CD-1, so line numbers refer to it.


Section 2.2.2 describes the original request context. This says that
the resource-id must be an XPath expression over the <Content>
element of the resource category. The scope attribute must be
"XPath-expression". Here is an example of such a request:


<Request

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

            <AttributeValue

              DataType="http://www.w3.org/2001/XMLSchema#string"

              >Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

            <md:record>

                <md:patient_info>

                    <md:name>Bart Simpson</md:name>

                </md:patient_info>

                <md:diagnosis_info>

                    <md:diagnosis>

                        <md:item type="primary">Gastric
Cancer</md:item>

                    </md:diagnosis>

                </md:diagnosis_info>                

            </md:record>

        </Content>

        <Attribute

              IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

            <AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

             
>md:record/descendant-or-self::node()</AttributeValue>

        </Attribute>

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">

            <AttributeValue

             
DataType="http://www.w3.org/2001/XMLSchema#string">XPath-expression</AttributeValue>

        </Attribute>

    </Attributes>

</Request>


Section 2.2.3 of the spec, lines 137-139, say that each node selected
by the XPath expression shall be considered as an individual request.
The rest of section 2.2.3 specifies how the individual requests are
produced. It simply states that each individual request is identitical
to the above request, except that the scope attribute is not present
and that the resource-id is replaced with an xpath which points to the
individual resource (each in turn).


There is no normative statement about the exact form of this XPath
expression, except that it must identify an individual node. Issue #11
from the public review concerns this XPath expression. As will be
clear, its exact form does not matter, which is the reason the
specification does not specify a particular form.


The Axiomatics implementation constructs the expression by referencing
the nodes by their order in the tree, so in our implementation the
individual requests look like this:



<Request

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

            <AttributeValue

              DataType="http://www.w3.org/2001/XMLSchema#string"

              >Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

            <md:record>

                <md:patient_info>

                    <md:name>Bart Simpson</md:name>

                </md:patient_info>

                <md:diagnosis_info>

                    <md:diagnosis>

                        <md:item type="primary">Gastric
Cancer</md:item>

                    </md:diagnosis>

                </md:diagnosis_info>                

            </md:record>

        </Content>

        <Attribute

              IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

            <AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

              >./*[1]/*[1]/*[1]</AttributeValue>

        </Attribute>

    </Attributes>

</Request>


For each individual request, the XPath expression "./*[1]/*[1]/*[1]"
will be different, like "./*[1]/*[1]/*[1]/text()[1]", "./*[1]/*[2]" and
so on, covering all nodes selected by the original XPath expression.
Other implementations may use another form, but this form is easy to
produce since we don't need to track element names, namespaces, etc,
just their order.


Somebody mentioned XML overhead before, so I will note that there is no
reason to construct each individual XML document in their entirety,
rather one can point to pieces of the orignial XML and keep a small
chache on the side for the resource-id value. So there is not really
any overhead to it. (In XACML 2.0 it is necessary to construct the full
<Request> XML since an XPath could be used to refer to any part
of it. That is not allowed in XACML 3.0, so the implementation can be
efficient.)


A policy could look like this:


<Policy

      xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record"

      PolicyId="urn:FIXME:policy1"

     
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

    <Target/>

    <Rule

          RuleId="urn:FIXME:rule1"

          Effect="Permit">

        <Target>

            <AnyOf>

                <AllOf>

                    <Match

                         
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

                        <AttributeValue

                             
DataType="http://www.w3.org/2001/XMLSchema#string">Julius
Hibbert</AttributeValue>

                        <AttributeDesignator

                             
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

                             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

                             
DataType="http://www.w3.org/2001/XMLSchema#string"/>

                    </Match>

                </AllOf>

            </AnyOf>

            <AnyOf>

                <AllOf>

                    <Match

                         
MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

                        <AttributeValue

                             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

                             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">

                              md:record/md:patient_info

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

                </AllOf>

            </AnyOf>

        </Target>

    </Rule>

</Policy>


This policy will allow Julius Hibbert access to the patient_info
section of the medical record, but not the rest. Note how the policy
uses an xpath match function, so the exact form of the xpath expression
is not significant.


So, there will be results like this:


The md:record/md:diagnosis element:


  <xacml-ctx:Result>

    <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[2]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>


The string "Bart Simpson":


  <xacml-ctx:Result>

    <xacml-ctx:Decision>Permit</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[1]/*[1]/text()[1]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>


The resource-id is part of the <Result>s since the original
resource-id has IncludeInResult="true", see the lines 144-147 in the
spec.


So, it is not true that the specification does not have any normative
statements of how the XPath "variant" works. Personally I also think
the text is quite clear. I can agree that the spec is not good learning
material, but I don't think that is the role of standard specification
since good learning material needs to be verbose and redundant because
one needs examples and different ways to explain the same thing to help
learning. But those are qualities which are undesirable in a technical
specification, so I would like to keep the text as it is.


Best regards,

Erik

The conceptual model for transforming xpath-selector resource-ids 
into individual node ids is sufficiently specified.  I just didn't see 
where it said what form of these individual ids should be returned in the 
xacml Response.  But I guess that is specified in the core spec under 
"IncludeInResult".
 
However, the core spec is not very helpful here.  A strict 
reading would say the PDP must only return attributes specified in the original 
request--not those added by the context handler.  Suppose the original 
request included one "role" attribute known to the PEP, 
with IncludeInResult=true.  The PDP evaluates policies with 
additional "role" attributes found by the PIP.  Should the result include 
just the original role attribute value, or all the values in the decision 
context?  Does "IncludeInResult" mean "include all values of this attribute 
type from the decision context" or "include just this attribute value from the 
original request"?  The MR profile defines "IncludeInResult" to mean 
"whatever value the implementation uses to describe an individual node 
using xpath" (for xpath resource-ids).  I can see this causing 
interoperability problems.
 
On a slightly different, but related topic, I think the ability 
to specify key attribute types would make it easier to implement and 
use the multiple request profile.  The original request could declare the 
set of key attribute ids for each decision, and the PDP would have 
to include those Attributes in each individual Result.  This 
would be much more flexible and precise than 
"IncludeInResult".
 
--Paul
 



  

  

  From: Erik Rissanen 
  [mailto:erik@axiomatics.com]
Sent: Friday, October 09, 2009 
  09:50
To: XACML TC
Subject: [xacml] Walkthrough of 
  multiple profile (related to public review issue #11)


  
All,

(I am mailing this in HTML since some of the lines are 
  long, and I don't want them to be cut off. I hope this works.)

One 
  issue which was brought up several times during the TC call yesterday was that 
  some TC members said that the multiple resource profile does not define in any 
  normative manner how the XPath based multiple request is divided into 
  individual requests. I don't agree, so here is a walkthrough of an example 
  with references to the specification.

The relevant section is 2.2 of 
  the multiple resource profile. I am using the PDF version of the CD-1, so line 
  numbers refer to it.

Section 2.2.2 describes the original request 
  context. This says that the resource-id must be an XPath expression over the 
  <Content> element of the resource category. The scope attribute must be 
  "XPath-expression". Here is an example of such a 
  request:

<Request
      
  xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
      
  xmlns:md="http://www.medico.com/schemas/record">
    
  <Attributes 
  Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
        
  <Attribute
              
  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
            
  <AttributeValue
              
  DataType="http://www.w3.org/2001/XMLSchema#string"
              
  >Julius 
  Hibbert</AttributeValue>
        
  </Attribute>
    
  </Attributes>
    <Attributes 
  Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
        
  <Content>
            
  <md:record>
                
  <md:patient_info>
                    
  <md:name>Bart 
  Simpson</md:name>
                
  </md:patient_info>
                
  <md:diagnosis_info>
                    
  <md:diagnosis>
                        
  <md:item type="primary">Gastric 
  Cancer</md:item>
                    
  </md:diagnosis>
                
  </md:diagnosis_info>               
   
            
  </md:record>
       
   </Content>
        
  <Attribute
              
  IncludeInResult="true"
              
  AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
            
  <AttributeValue
              
  XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              
  DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
              
  >md:record/descendant-or-self::node()</AttributeValue>
        
  </Attribute>
        
  <Attribute
              
  AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">
            
  <AttributeValue
              
  DataType="http://www.w3.org/2001/XMLSchema#string">XPath-expression</AttributeValue>
        
  </Attribute>
    
  </Attributes>
</Request>

Section 2.2.3 of the spec, 
  lines 137-139, say that each node selected by the XPath expression shall be 
  considered as an individual request. The rest of section 2.2.3 specifies how 
  the individual requests are produced. It simply states that each individual 
  request is identitical to the above request, except that the scope attribute 
  is not present and that the resource-id is replaced with an xpath which points 
  to the individual resource (each in turn).

There is no normative 
  statement about the exact form of this XPath expression, except that it must 
  identify an individual node. Issue #11 from the public review concerns this 
  XPath expression. As will be clear, its exact form does not matter, which is 
  the reason the specification does not specify a particular form.

The 
  Axiomatics implementation constructs the expression by referencing the nodes 
  by their order in the tree, so in our implementation the individual requests 
  look like this:


<Request
      
  xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
      
  xmlns:md="http://www.medico.com/schemas/record">
    
  <Attributes 
  Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
        
  <Attribute
              
  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
            
  <AttributeValue
              
  DataType="http://www.w3.org/2001/XMLSchema#string"
              
  >Julius 
  Hibbert</AttributeValue>
        
  </Attribute>
    
  </Attributes>
    <Attributes 
  Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
        
  <Content>
            
  <md:record>
                
  <md:patient_info>
                    
  <md:name>Bart 
  Simpson</md:name>
                
  </md:patient_info>
                
  <md:diagnosis_info>
                    
  <md:diagnosis>
                        
  <md:item type="primary">Gastric 
  Cancer</md:item>
                    
  </md:diagnosis>
                
  </md:diagnosis_info>               
   
            
  </md:record>
       
   </Content>
        
  <Attribute
              
  IncludeInResult="true"
              
  AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
            
  <AttributeValue
              
  XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
              
  DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
              
  >./*[1]/*[1]/*[1]</AttributeValue>
        
  </Attribute>
    
  </Attributes>
</Request>

For each individual request, 
  the XPath expression "./*[1]/*[1]/*[1]" will be different, like 
  "./*[1]/*[1]/*[1]/text()[1]", "./*[1]/*[2]" and so on, covering all nodes 
  selected by the original XPath expression. Other implementations may use 
  another form, but this form is easy to produce since we don't need to track 
  element names, namespaces, etc, just their order.

Somebody mentioned 
  XML overhead before, so I will note that there is no reason to construct each 
  individual XML document in their entirety, rather one can point to pieces of 
  the orignial XML and keep a small chache on the side for the resource-id 
  value. So there is not really any overhead to it. (In XACML 2.0 it is 
  necessary to construct the full <Request> XML since an XPath could be 
  used to refer to any part of it. That is not allowed in XACML 3.0, so the 
  implementation can be efficient.)

A policy could look like 
  this:

<Policy
      
  xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
      
  xmlns:md="http://www.medico.com/schemas/record"
      
  PolicyId="urn:FIXME:policy1"
      
  RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
    
  <Target/>
    
  <Rule
          
  RuleId="urn:FIXME:rule1"
          
  Effect="Permit">
        
  <Target>
            
  <AnyOf>
                
  <AllOf>
                    
  <Match
                          
  MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                        
  <AttributeValue
                              
  DataType="http://www.w3.org/2001/XMLSchema#string">Julius 
  Hibbert</AttributeValue>
                        
  <AttributeDesignator
                              
  Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                              
  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                              
  DataType="http://www.w3.org/2001/XMLSchema#string"/>
                    
  </Match>
                
  </AllOf>
            
  </AnyOf>
            
  <AnyOf>
                
  <AllOf>
                    
  <Match
                          
  MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">
                        
  <AttributeValue
                              
  XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                              
  DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">
                              
  md:record/md:patient_info
                        
  </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>
                
  </AllOf>
            
  </AnyOf>
        
  </Target>
    
  </Rule>
</Policy>

This policy will allow Julius Hibbert 
  access to the patient_info section of the medical record, but not the rest. 
  Note how the policy uses an xpath match function, so the exact form of the 
  xpath expression is not significant.

So, there will be results like 
  this:

The md:record/md:diagnosis element:

  
  <xacml-ctx:Result>
    
  <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision>
    
  <xacml-ctx:Status>
      
  <xacml-ctx:StatusCode 
  Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    
  </xacml-ctx:Status>
    <xacml-ctx:Attributes 
  Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      
  <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
  IncludeInResult="true">
        
  <xacml-ctx:AttributeValue 
  XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
  DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[2]</xacml-ctx:AttributeValue>
      
  </xacml-ctx:Attribute>
    
  </xacml-ctx:Attributes>
  </xacml-ctx:Result>

The 
  string "Bart Simpson":

  
  <xacml-ctx:Result>
    
  <xacml-ctx:Decision>Permit</xacml-ctx:Decision>
    
  <xacml-ctx:Status>
      
  <xacml-ctx:StatusCode 
  Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    
  </xacml-ctx:Status>
    <xacml-ctx:Attributes 
  Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
      
  <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
  IncludeInResult="true">
        
  <xacml-ctx:AttributeValue 
  XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
  DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[1]/*[1]/text()[1]</xacml-ctx:AttributeValue>
      
  </xacml-ctx:Attribute>
    
  </xacml-ctx:Attributes>
  </xacml-ctx:Result>

The 
  resource-id is part of the <Result>s since the original resource-id has 
  IncludeInResult="true", see the lines 144-147 in the spec.

So, it is 
  not true that the specification does not have any normative statements of how 
  the XPath "variant" works. Personally I also think the text is quite clear. I 
  can agree that the spec is not good learning material, but I don't think that 
  is the role of standard specification since good learning material needs to be 
  verbose and redundant because one needs examples and different ways to explain 
  the same thing to help learning. But those are qualities which are undesirable 
  in a technical specification, so I would like to keep the text as it 
  is.

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 

Paul,

I think the main issue here is that the XACML Request is described as an 
abstract concept, not a wire protocol. In most implementations there 
would be

1. An initial access request defined with the XACML 

Erik, you're right about the two different ways of thinking about this.
I always think of it in terms of request/response protocol, where the
PEP knows nothing of what goes on inside the PDP, and the PDP makes no
assumptions about what the PEP will do with the result.  In this model,
the PEP must have a sufficiently well-defined vocabulary for requesting
what it needs to do its job.  And, the semantics of the response must be
sufficiently well-defined to prevent variant interpretations.

I think we've established that "IncludeInResult" needs better
definition.  But there may be a better way to meet at least one of the
purposes of IncludeInResult--specifying how multiple returned Decisions
will be identified.

Defining a DecisionKeyAttributes construct in the Request vocabulary
would allow the PEP to declare how it wants the Decisions identified in
the Response.  "IncludeInResult" is a round-about way of doing this, but
does not carry the direct semantics that you want in a formal system.
It is also limited to attributes that the PEP already has a value for.

Suppose we want to ask which versions of a document Athena can read, and
which she can modify.  The PEP doesn't know what versions of the
document exist, so can't send Attribute[@AttributeId = 'version-id'].
But it could send a request that included the access-subject, the
document identifier, the two action-ids, and a DecisionKeyAttributes
like:



The policies may not even consider "version-id", but the context handler
would be expected to supply all version-ids for the document, and the
Individual Requests would then be formed for each unique combination of
the DecisionKeyAttributes, which would all be included in the Result for
each Decision.

Aside from the benefit of being able to request attribute return values
that weren't in the orginal request, it is easier to describe the
expected behavior of this approach.  You could also define a
transformation from any request that has "IncludeInResult=true"
attributes to an equivalent request with a DecisionKeyAttributes element
(assuming that the only purpose of IncludeInResult is to provide a sort
of "key" functionality).

Regards,
--Paul


> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Monday, October 12, 2009 08:07
> To: Tyson, Paul H
> Cc: XACML TC
> Subject: Re: [xacml] Walkthrough of multiple profile (related 
> to public review issue #11)
> 
> Paul,
> 
> I think the main issue here is that the XACML Request is 
> described as an abstract concept, not a wire protocol. In 
> most implementations there would be
> 
> 1. An initial access request defined with the XACML 

Hi Erik,

thanks for giving the
insides of your use of the multiple resource profile.

Actually my understanding
is pretty close to yours with two exceptions:



1. The scope value MUST
not be “XPath-expression”.

It can be Descendant too.
Therefore my question: is the following equal (and if so is the allowed redundancy
in the xml use case unnecessary?):

a)

-global resource-id=md:record/descendant-or-self::node()

-scope= XPath-expression

b)

-global resource-id=md:record

-scope= Descendant



2: Further you are
saying:

“As will be clear,
its exact form does not matter, which is the reason the specification does not
specify a particular form.”

That is true in your case
as you are using the xpath-node-match function to evaluate the resource-id value.
The advantage of using the xpath-node-match function is that it abstracts from the
exact form of the xpath expression. So if you use this function your conclusion
is valid. If you use another function like reg-exp-string match function (which
is allowed according to the profile) the exact form will mater if you want to keep
interoperability. That brings us to the topic we discussed already in various mails.
Should the perfomant to evaluate reg-exp-string match function be allowed as an
additional alternative to the more expansive to evaluate xpath-node-match
function calls. The performance optimization you mention just refers to the dom
representation. It doesn’t avoid the “expensive” xpath
evaluations (the arguments of the n xpath-node-match-function calls –n equals
the number of individual nodes/resource-ids ) against this dom.

 However we decide a
decision is needed as e.g. your individual decision requests won’t match rules
checking the resource-id values with the reg-exp-match function.



Best regards

jan

 




















Von: Erik Rissanen [mailto:erik@axiomatics.com]

Gesendet: Freitag, 9. Oktober 2009
16:50

An: XACML TC

Betreff: [xacml] Walkthrough of
multiple profile (related to public review issue #11)





All,


(I am mailing this in HTML since some of the lines are long, and I don't want
them to be cut off. I hope this works.)


One issue which was brought up several times during the TC call yesterday was
that some TC members said that the multiple resource profile does not define in
any normative manner how the XPath based multiple request is divided into
individual requests. I don't agree, so here is a walkthrough of an example with
references to the specification.


The relevant section is 2.2 of the multiple resource profile. I am using the
PDF version of the CD-1, so line numbers refer to it.


Section 2.2.2 describes the original request context. This says that the
resource-id must be an XPath expression over the <Content> element of the
resource category. The scope attribute must be "XPath-expression".
Here is an example of such a request:


<Request

     
xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

           
<AttributeValue

             
DataType="http://www.w3.org/2001/XMLSchema#string"

             
>Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

           
<md:record>

               
<md:patient_info>

                   
<md:name>Bart Simpson</md:name>

               
</md:patient_info>

               
<md:diagnosis_info>

                   
<md:diagnosis>

                       
<md:item type="primary">Gastric Cancer</md:item>

                   
</md:diagnosis>

               
</md:diagnosis_info>              
 

           
</md:record>

        </Content>

        <Attribute

             
IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

           
<AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

             
>md:record/descendant-or-self::node()</AttributeValue>

        </Attribute>

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">

           
<AttributeValue

             
DataType="http://www.w3.org/2001/XMLSchema#string">XPath-expression</AttributeValue>

        </Attribute>

    </Attributes>

</Request>


Section 2.2.3 of the spec, lines 137-139, say that each node selected by the
XPath expression shall be considered as an individual request. The rest of
section 2.2.3 specifies how the individual requests are produced. It simply
states that each individual request is identitical to the above request, except
that the scope attribute is not present and that the resource-id is replaced
with an xpath which points to the individual resource (each in turn).


There is no normative statement about the exact form of this XPath expression,
except that it must identify an individual node. Issue #11 from the public
review concerns this XPath expression. As will be clear, its exact form does
not matter, which is the reason the specification does not specify a particular
form.


The Axiomatics implementation constructs the expression by referencing the
nodes by their order in the tree, so in our implementation the individual
requests look like this:



<Request

     
xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record">

    <Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">

        <Attribute

             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">

           
<AttributeValue

             
DataType="http://www.w3.org/2001/XMLSchema#string"

             
>Julius Hibbert</AttributeValue>

        </Attribute>

    </Attributes>

    <Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

        <Content>

           
<md:record>

               
<md:patient_info>

                   
<md:name>Bart Simpson</md:name>

               
</md:patient_info>

               
<md:diagnosis_info>

                   
<md:diagnosis>

                       
<md:item type="primary">Gastric Cancer</md:item>

                   
</md:diagnosis>

               
</md:diagnosis_info>              
 

           
</md:record>

        </Content>

        <Attribute

             
IncludeInResult="true"

             
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">

           
<AttributeValue

             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"

             
>./*[1]/*[1]/*[1]</AttributeValue>

        </Attribute>

    </Attributes>

</Request>


For each individual request, the XPath expression "./*[1]/*[1]/*[1]"
will be different, like "./*[1]/*[1]/*[1]/text()[1]",
"./*[1]/*[2]" and so on, covering all nodes selected by the original
XPath expression. Other implementations may use another form, but this form is
easy to produce since we don't need to track element names, namespaces, etc,
just their order.


Somebody mentioned XML overhead before, so I will note that there is no reason
to construct each individual XML document in their entirety, rather one can
point to pieces of the orignial XML and keep a small chache on the side for the
resource-id value. So there is not really any overhead to it. (In XACML 2.0 it
is necessary to construct the full <Request> XML since an XPath could be
used to refer to any part of it. That is not allowed in XACML 3.0, so the
implementation can be efficient.)


A policy could look like this:


<Policy

     
xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"

      xmlns:md="http://www.medico.com/schemas/record"

      PolicyId="urn:FIXME:policy1"

     
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

    <Target/>

    <Rule

         
RuleId="urn:FIXME:rule1"

          Effect="Permit">

        <Target>

           
<AnyOf>

               
<AllOf>

                   
<Match

                         
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

                       
<AttributeValue

                             
DataType="http://www.w3.org/2001/XMLSchema#string">Julius
Hibbert</AttributeValue>

                       
<AttributeDesignator

                             
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"

                             
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

                             
DataType="http://www.w3.org/2001/XMLSchema#string"/>

                   
</Match>

               
</AllOf>

           
</AnyOf>

           
<AnyOf>

               
<AllOf>

                   
<Match

                         
MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">

                       
<AttributeValue

                             
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"

                             
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">

                             
md:record/md:patient_info

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

               
</AllOf>

            </AnyOf>

        </Target>

    </Rule>

</Policy>


This policy will allow Julius Hibbert access to the patient_info section of the
medical record, but not the rest. Note how the policy uses an xpath match
function, so the exact form of the xpath expression is not significant.


So, there will be results like this:


The md:record/md:diagnosis element:


  <xacml-ctx:Result>

   
<xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[2]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>


The string "Bart Simpson":


  <xacml-ctx:Result>

    <xacml-ctx:Decision>Permit</xacml-ctx:Decision>

    <xacml-ctx:Status>

      <xacml-ctx:StatusCode
Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

    </xacml-ctx:Status>

    <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">

      <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true">

        <xacml-ctx:AttributeValue
XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[1]/*[1]/text()[1]</xacml-ctx:AttributeValue>

      </xacml-ctx:Attribute>

    </xacml-ctx:Attributes>

  </xacml-ctx:Result>


The resource-id is part of the <Result>s since the original resource-id
has IncludeInResult="true", see the lines 144-147 in the spec.


So, it is not true that the specification does not have any normative
statements of how the XPath "variant" works. Personally I also think
the text is quite clear. I can agree that the spec is not good learning
material, but I don't think that is the role of standard specification since
good learning material needs to be verbose and redundant because one needs
examples and different ways to explain the same thing to help learning. But
those are qualities which are undesirable in a technical specification, so I
would like to keep the text as it is.


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

Hi Jan,

See inline.

Jan Herrmann wrote:
>
> Hi Erik,
>
> thanks for giving the insides of your use of the multiple resource 
> profile.
>
> Actually my understanding is pretty close to yours with two exceptions:
>
> 1. The scope value MUST not be “XPath-expression”.
>
> It can be Descendant too. Therefore my question: is the following 
> equal (and if so is the allowed redundancy in the xml use case 
> unnecessary?):
>
> a)
>
> -global resource-id=md:record/descendant-or-self::node()
>
> -scope= XPath-expression
>
> b)
>
> -global resource-id=md:record
>
> -scope= Descendant
>

They would appear to be equivalent to me.

> 2: Further you are saying:
>
> “As will be clear, its exact form does not matter, which is the reason 
> the specification does not specify a particular form.”
>
> That is true in your case as you are using the xpath-node-match 
> function to evaluate the resource-id value. The advantage of using the 
> xpath-node-match function is that it abstracts from the exact form of 
> the xpath expression. So if you use this function your conclusion is 
> valid. If you use another function like reg-exp-string match function 
> (which is allowed according to the profile) the exact form will mater 
> if you want to keep interoperability. That brings us to the topic we 
> discussed already in various mails. Should the perfomant to evaluate 
> reg-exp-string match function be allowed as an additional alternative 
> to the more expansive to evaluate xpath-node-match function calls. The 
> performance optimization you mention just refers to the dom 
> representation. It doesn’t avoid the “expensive” xpath evaluations 
> (the arguments of the n xpath-node-match-function calls –n equals the 
> number of individual nodes/resource-ids ) against this dom.
>
> However we decide a decision is needed as e.g. your individual 
> decision requests won’t match rules checking the resource-id values 
> with the reg-exp-match function.
>

Yes, it appears to me too that the discussion is going in circles.

So can you make a concrete proposal with specific text for how you would 
like to change the profile, so we can move forward?

Do you have performance numbers which show that XPath evaluation is in 
fact a performance issue? Keep in mind that regexp matching is not free 
either.

Best regards,
Erik

> Best regards
>
> jan
>
>
>
> ------------------------------------------------------------------------
>
> *Von:* Erik Rissanen [mailto:erik@axiomatics.com]
> *Gesendet:* Freitag, 9. Oktober 2009 16:50
> *An:* XACML TC
> *Betreff:* [xacml] Walkthrough of multiple profile (related to public 
> review issue #11)
>
> All,
>
> (I am mailing this in HTML since some of the lines are long, and I 
> don't want them to be cut off. I hope this works.)
>
> One issue which was brought up several times during the TC call 
> yesterday was that some TC members said that the multiple resource 
> profile does not define in any normative manner how the XPath based 
> multiple request is divided into individual requests. I don't agree, 
> so here is a walkthrough of an example with references to the 
> specification.
>
> The relevant section is 2.2 of the multiple resource profile. I am 
> using the PDF version of the CD-1, so line numbers refer to it.
>
> Section 2.2.2 describes the original request context. This says that 
> the resource-id must be an XPath expression over the 

 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Wednesday, October 14, 2009 10:19
> To: Jan Herrmann
> Cc: xacml@lists.oasis-open.org
> Subject: Re: AW: [xacml] Walkthrough of multiple profile 
> (related to public review issue #11)
> 
> Yes, it appears to me too that the discussion is going in circles.
> 
> So can you make a concrete proposal with specific text for 
> how you would like to change the profile, so we can move forward?
>

I do not think we are ready to consider textual amendments to the
profile without further discussion of the issues.

We might be close to putting specific proposals up for vote, so we
should try to collect those proposals.  Unfortunately, they are not
orthogonal, but we can at least group the related ones together and
consider each group.

I think Jan is proposing:

#1: Specify the form of the generated xpath resource-id when creating
single decision requests from a multiple decision request, so that it
can be tested with regexp match.

I have several objections to this proposal, but I think another defect
should be addressed first:

#2: Do not allow context handler to change attribute values supplied in
the original request context.

The notional model of creating single decision requests from a multiple
decision request introduces this requirement in the case of xpath
resource-ids.  It should be remedied, either by changing the original
request attribute id to "resource-selector", or the generated attribute
ids to something like "authorized-node-id", or "decision-resource-id".

Rich has proposed:

#3: Provide an alternate resource identification method, using
namespaced URIs to describe portions of an XML document that is not
available in the decision context.

And my favorite:

#4: Provide an optional attribute on AttributeSelector to set the
context for xpath evaluation at the node on which the decision is
requested.

And there are more.

We should try to move from discussing issues to submitting proposals
that can be voted on.  But the discussion has been very good, and we're
not through yet (or maybe I'm just slower than than the rest).

Regards
--Paul

Paul,

 From my experience in working within the XACML TC, I would say that in 
many cases the best way to discuss things is to propose concrete 
changes. There are several problems with discussing just ideas. Ideas 
are ambiguous since the idea still needs to be transformed into a 
concrete spec. It is much clearer to go directly to the spec. 
(Naturally, there is also a role for idea sketching as well early on 
since a full proposed change can be lots of effort to do.) I understand 
Rich's ideas much better with his proposal, than without it.

Another benefit of a concrete proposal is that if the proposal is good, 
then that's part of the delivery of the spec, meaning that we have done 
meaningful work. So it may be waste of time to spend lots of time 
writing down ideas in a form which cannot be a part of a spec in the end.

So, I think it is time to start presenting the ideas in more concrete 
form. Then all the problems as well with the ideas will surface. For 
instance, it is easy to say that we need to define a form of xpath 
expressions which can be regexp-matched. I don't think that is so easy, 
and I would invite a concrete proposal from the proponents of that idea. 
Then you will see all the issues. ;-)

Anyway, I get the feeling that the multiple and hierarchical profiles 
are not going to be ready anytime soon, and I think we should consider 
dropping them from this round and give them another six months or so to 
mature. I think the attribute selector with the offset can fix the 
multiple profile for XPath, so we can put that in the current core and 
go with that, and do the rest of multiple and hierarchical when they are 
ready.

Best regards,
Erik



Tyson, Paul H wrote:
>  
>
>   
>> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com] 
>> Sent: Wednesday, October 14, 2009 10:19
>> To: Jan Herrmann
>> Cc: xacml@lists.oasis-open.org
>> Subject: Re: AW: [xacml] Walkthrough of multiple profile 
>> (related to public review issue #11)
>>
>> Yes, it appears to me too that the discussion is going in circles.
>>
>> So can you make a concrete proposal with specific text for 
>> how you would like to change the profile, so we can move forward?
>>
>>     
>
> I do not think we are ready to consider textual amendments to the
> profile without further discussion of the issues.
>
> We might be close to putting specific proposals up for vote, so we
> should try to collect those proposals.  Unfortunately, they are not
> orthogonal, but we can at least group the related ones together and
> consider each group.
>
> I think Jan is proposing:
>
> #1: Specify the form of the generated xpath resource-id when creating
> single decision requests from a multiple decision request, so that it
> can be tested with regexp match.
>
> I have several objections to this proposal, but I think another defect
> should be addressed first:
>
> #2: Do not allow context handler to change attribute values supplied in
> the original request context.
>
> The notional model of creating single decision requests from a multiple
> decision request introduces this requirement in the case of xpath
> resource-ids.  It should be remedied, either by changing the original
> request attribute id to "resource-selector", or the generated attribute
> ids to something like "authorized-node-id", or "decision-resource-id".
>
> Rich has proposed:
>
> #3: Provide an alternate resource identification method, using
> namespaced URIs to describe portions of an XML document that is not
> available in the decision context.
>
> And my favorite:
>
> #4: Provide an optional attribute on AttributeSelector to set the
> context for xpath evaluation at the node on which the decision is
> requested.
>
> And there are more.
>
> We should try to move from discussing issues to submitting proposals
> that can be voted on.  But the discussion has been very good, and we're
> not through yet (or maybe I'm just slower than than the rest).
>
> Regards
> --Paul
>