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:]
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
