[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