[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