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