MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [xacml] AttributeSelector example
This is a proposed policy specification using AttributeSelector.
In the current draft, there is a policy fragment (line 799-805):
<ResourceMatch MatchId="function:node-match">
<ResourceAttributeDesignator AttributeId
="urn:oasis:names:tc:xacml:resource:xpath"
DataType="xsi:string"/>
<AttributeValue DataType="xsi:string">/md:record</AttributeValue>
</ResourceMatch>
The above is not correct usage of node-match function. I would propose the
following:
Expression A:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextId
="urn:oasis:names:tc:xacml:resource:xpath">
<AttributeSelector RequestContextPath="//ctx:ResourceContent/md:record
| //ctx:ResourceContent/md:record//md:*">
<XPathNamespace NamespaceURI="urn:oasis:names:tc:xacml:0.16g:context"
Prefix="ctx"/>
<XPathNamespace NamespaceURI="http:www.medico.com/schemas/record.xsd"
Prefix="md"/>
</AttributeSelector>
</ResourceMatch>
1) I posted the node-match function addition request in the separate mail
saying that:
=====================
<3>. Function:node-match
boolean node-match(object, object)
The result of a node-match is defined by applying the following rules, in
order:
1. Both operands must be either a single node or an empty set; otherwise
the error value is returned.
2. If either operand is an empty set, the result of the comparison is an
empty set.
3. A comparison is true if the two operands are nodes that have the same
single node; otherwise it is false.
An example specification is:
<Rule>
<Target>
<Resources MatchId="function:node-match" DataType="xs:boolean">
<AttributeSelector RequestContextPath="//b1"/>
<AttributeSelector RequestContextPath="/a/b1"/>
</Resource>
</Target>
</Rule>
If "//b1" and "/a/b1" contains one or more intersection node, then the
node-match function returns true, otherwise returns false.
=====================
2) AttributeSelector has a new attribute "RequestContextId"
"RequestContextId" attribute indicates that the xpath expression is written
in the context referred by the attribute id (i.e.
urn:oasis:names:tc:xacml:resource:xpath). In the Rule1 example in the spec,
that attribute is
"xmlns(md=http:www.medico.com/schemas/record.xsd)xpointer(/md:record/md:patient/md:patientDoB".
Using this value, the expression (Expression A) can be translated to:
Expression B:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextPath
="//ctx:ResourceContent/md:record/md:patient/md:patientDoB">
<XPathNamespace NamespaceURI="urn:oasis:names:tc:xacml:0.16g:context"
Prefix="ctx"/>
<XPathNamespace NamespaceURI="http:www.medico.com/schemas/record.xsd"
Prefix="md"/>
</AttributeSelector>
<AttributeSelector RequestContextPath="//ctx:ResourceContent/md:record
| //ctx:ResourceContent/md:record//md:*"/>
<XPathNamespace NamespaceURI="urn:oasis:names:tc:xacml:0.16g:context"
Prefix="ctx"/>
<XPathNamespace NamespaceURI="http:www.medico.com/schemas/record.xsd"
Prefix="md"/>
</AttributeSelector>
</ResourceMatch>
Note that the first AttributeSelector's Path is headed by
"//ctx:ResourceContent" because this is necessary to correctly navigate to
"md:record". Both path expressions are applied with namespace information.
The first xpath returns md:patientDoB element. The second xpath returns all
the element equal to or descendant of md:record elements (e.g. md:record,
md:patient, ..., md:patientDoB, etc.). Since md:patientDoB element is
included in both the first and the second node set, function:node-match
returns true.
3) Namespace
Namespace information is necessary to parse the XPath expression. Those are
specfied below the AttributeSelector element using <XPathNamespace> element
as Expression B.
4) Policy Defaults
Since XPathNamespace specification is repeated in any place, it would be
wise to specify it at one place like policy defaults. So the Expression B
becomes:
Expression C:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextPath
="//ctx:ResourceContent/md:record/md:patient/md:patientDoB"/
<AttributeSelector RequestContextPath="//ctx:ResourceContent/md:record
| //ctx:ResourceContent/md:record//md:*"/>
</ResourceMatch>
with
<Policy>
<PolicyDefaults>
<XPathNamespace NamespaceURI="urn:oasis:names:tc:xacml:0.16g:context"
Prefix="ctx"/>
<XPathNamespace NamespaceURI="http:www.medico.com/schemas/record.xsd"
Prefix="md"/>
</PolicyDefaults>
...
</Policy>
Michiharu Kudo
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC