There are several instances in the policy schema
where we pass xpath expressions as arguments.
1. In the case of <xacml:AttributeSelector>
element RequestContextPath attribute contains xpath expression
that selects xacml attribute value from the
context.
2. When xpath functions are used in the target, the
value to match agains is xpath expression.
When xpath functions are used in conditions they
take xpath expressions as arguments.
All examples are from section 4.2
For the attribute-selector we use XPathNamespace
element that maps namespace uri to namespace prefix
(essentially duplicating standard xml namespace
declaration)
AttributeSelector:
<AttributeSelector
RequestContextPath=
"//ctx:RequestContext/md:record/md:patient/md:policyNumber">
<XPathNamespace
NamespaceURI="urn:names:tc:xacml:1.0:context"
Prefix="ctx"/>
</AttributeSelector>
For other uses of xpath functions we do not have
special provisions for namespace mapping.
Here is how xpath expression is used in the target
to match request:
<ResourceMatch
matchId="function:xpath-match">
<ResourceAttributeDesignator
AttributeId=
"urn:oasis:names:tc:xacml:1.0:resource:xpath"/>
<AttributeValue>/md:record</AttributeValue> </ResourceMatch>
In this case we rely on standard xml namespace
declaration for the md prefix.
To summarise: we use two methods to deal with the
same problem: one is standard and one is not.
Proposal: 1. Use standard xml namespace
declarations mechanism in both cases and drop <XPathNamespace>
element.
2. Change RequestContextType attribute of
AttributeSelector to xs:string (it is currently xs:anyURI).
Simon
|