[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] AttributeSelector example
Simon
>Current schema allows to match attribute-selector with attribute-value.
>Do you think this is something we have to change?
I think so.
>I'm not sure why you need attribute-selector with request-context-id
>attribute.
>Attribute-designator should be used for that.
If you specify an Attribute-designator under ResourceMatch element, it just
means that "retrieve attribute value from context". It means nothing about
"to apply the retrieved value against the context and return objects". In
my definition, the node-match function is not stiring-based matching
function but XPath-based node-identity-based matching function (this is
needed because a user may submit a request to /a//b that never be resolved
using string-based matching). I described the function definition in
http://lists.oasis-open.org/archives/xacml/200208/msg00142.html. Then I
thought just specifying <ResourceAttributeDesignator> under <ResourceMatch>
is something different I need. In other words, my intention is something
like:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextPath='<ResourceAttributeDesignator
AttributeId="urn:...:resource:xpath"/>'/>
<AttributeSelector RequestContextPath=" ... ">
</ResourceMatch>
The above intention became:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextId="urn:...:resource:xpath"/>
<AttributeSelector RequestContextPath=" ... "/>
</ResourceMatch>
In my definition, <AttributeSelector> is a XPath function that returns
object from XPath expression. The node-match function receives two object
arguments and returns boolean Therefore, I thought we need to specify two
<AttributeSelector> instead of pair of <ResourceAttributeDesignator> and
<AttributeSelector>. Does it make sense?
>Even if you have attribute-selector with request-context-id attribute it
is
>not clear
>which attribute you are referring to. It just so happens that attribute
>identifier has 'resource'
>in it, but it is not the general rule.
Is it not clear? Since the attribute id
"urn:oasis:names:toc:xacml:resource:xpath" is clearly specified, it seems
no ambiguity in referring the value, that is
"xmlns(md=http:www.medico.com/schemas/record.xsd)xpointer(/md:record/md:patient/md:patientDoB"
from the context. An argument would be that no syntax of the xpath
attribute is specified in the rule. So we may need to specify:
<ResourceMatch MatchId="function:node-match">
<AttributeSelector RequestContextId="urn:...:resource:xpath" DataType
="XPointer"/>
<AttributeSelector RequestContextPath=" ... "/>
</ResourceMatch>
Then PDP definitely comes to know what conversion is necessary (from
XPointer to XPath with Namespace element). Moreover, 'XPointer' should be
'urn:oasis:names:tc:xacml:resource:syntax:xpointer', although I proposed
'XPointer' in the previous mail.
>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
I changed the name from node-equal because node-equal is defined in XPath
2.0 that compares two nodes, not compares two node-set with existential
semantics. Another name would be general-node-equal. Which one do you
prefer?
Michiharu
IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
Simon Godik
<simon@godik.com> To: XACML TC <xacml@lists.oasis-open.org>
cc:
2002/08/25 09:16 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>
>
>
>
----------------------------------------------------------------
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