OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] AttributeSelector example


Michiharu,
I'm a little confused by this example.

Expression (A) has 2 attribute-selector children of the <resource-match>
element.
Current schema allows to match attribute-selector with attribute-value.
Do you think this is something we have to change?

I'm not sure why you need attribute-selector with request-context-id
attribute.
Attribute-designator should be used for that.

Even if you have attribute-selector with request-context-id attribute it is
not clear
which attribute you are refering to. It just so happens that attribute
identifier has 'resource'
in it, but it is not the general rule.

I think what you call node-match function used to be called node-equal
function before.
In section 3 example node-match is not explained, but I had following in
mind:
node-match(xpath-req, xpath-rule), meaning that if xpath-req node is in
xpath-rule node-set than there is a match.

Simon

----- Original Message -----
From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
To: "XACML TC" <xacml@lists.oasis-open.org>
Sent: Saturday, August 24, 2002 2:44 AM
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:pati
ent/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
>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC