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] | [List Home]


Subject: Re: AW: [xacml] Walkthrough of multiple profile (related to publicreview issue #11)


Hi Jan,

See inline.

Jan Herrmann wrote:
>
> Hi Erik,
>
> thanks for giving the insides of your use of the multiple resource 
> profile.
>
> Actually my understanding is pretty close to yours with two exceptions:
>
> 1. The scope value MUST not be “XPath-expression”.
>
> It can be Descendant too. Therefore my question: is the following 
> equal (and if so is the allowed redundancy in the xml use case 
> unnecessary?):
>
> a)
>
> -global resource-id=md:record/descendant-or-self::node()
>
> -scope= XPath-expression
>
> b)
>
> -global resource-id=md:record
>
> -scope= Descendant
>

They would appear to be equivalent to me.

> 2: Further you are saying:
>
> “As will be clear, its exact form does not matter, which is the reason 
> the specification does not specify a particular form.”
>
> That is true in your case as you are using the xpath-node-match 
> function to evaluate the resource-id value. The advantage of using the 
> xpath-node-match function is that it abstracts from the exact form of 
> the xpath expression. So if you use this function your conclusion is 
> valid. If you use another function like reg-exp-string match function 
> (which is allowed according to the profile) the exact form will mater 
> if you want to keep interoperability. That brings us to the topic we 
> discussed already in various mails. Should the perfomant to evaluate 
> reg-exp-string match function be allowed as an additional alternative 
> to the more expansive to evaluate xpath-node-match function calls. The 
> performance optimization you mention just refers to the dom 
> representation. It doesn’t avoid the “expensive” xpath evaluations 
> (the arguments of the n xpath-node-match-function calls –n equals the 
> number of individual nodes/resource-ids ) against this dom.
>
> However we decide a decision is needed as e.g. your individual 
> decision requests won’t match rules checking the resource-id values 
> with the reg-exp-match function.
>

Yes, it appears to me too that the discussion is going in circles.

So can you make a concrete proposal with specific text for how you would 
like to change the profile, so we can move forward?

Do you have performance numbers which show that XPath evaluation is in 
fact a performance issue? Keep in mind that regexp matching is not free 
either.

Best regards,
Erik

> Best regards
>
> jan
>
>
>
> ------------------------------------------------------------------------
>
> *Von:* Erik Rissanen [mailto:erik@axiomatics.com]
> *Gesendet:* Freitag, 9. Oktober 2009 16:50
> *An:* XACML TC
> *Betreff:* [xacml] Walkthrough of multiple profile (related to public 
> review issue #11)
>
> All,
>
> (I am mailing this in HTML since some of the lines are long, and I 
> don't want them to be cut off. I hope this works.)
>
> One issue which was brought up several times during the TC call 
> yesterday was that some TC members said that the multiple resource 
> profile does not define in any normative manner how the XPath based 
> multiple request is divided into individual requests. I don't agree, 
> so here is a walkthrough of an example with references to the 
> specification.
>
> The relevant section is 2.2 of the multiple resource profile. I am 
> using the PDF version of the CD-1, so line numbers refer to it.
>
> Section 2.2.2 describes the original request context. This says that 
> the resource-id must be an XPath expression over the <Content> element 
> of the resource category. The scope attribute must be 
> "XPath-expression". Here is an example of such a request:
>
> <Request
> xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
> xmlns:md="http://www.medico.com/schemas/record"; 
> <http://www.medico.com/schemas/record>>
> <Attributes 
> Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
> <Attribute
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string"; 
> <http://www.w3.org/2001/XMLSchema#string>
> >Julius Hibbert</AttributeValue>
> </Attribute>
> </Attributes>
> <Attributes 
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
> <Content>
> <md:record>
> <md:patient_info>
> <md:name>Bart Simpson</md:name>
> </md:patient_info>
> <md:diagnosis_info>
> <md:diagnosis>
> <md:item type="primary">Gastric Cancer</md:item>
> </md:diagnosis>
> </md:diagnosis_info>
> </md:record>
> </Content>
> <Attribute
> IncludeInResult="true"
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
> <AttributeValue
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
> >md:record/descendant-or-self::node()</AttributeValue>
> </Attribute>
> <Attribute
> AttributeId="urn:oasis:names:tc:xacml:2.0:resource:scope">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string"; 
> <http://www.w3.org/2001/XMLSchema#string>>XPath-expression</AttributeValue>
> </Attribute>
> </Attributes>
> </Request>
>
> Section 2.2.3 of the spec, lines 137-139, say that each node selected 
> by the XPath expression shall be considered as an individual request. 
> The rest of section 2.2.3 specifies how the individual requests are 
> produced. It simply states that each individual request is identitical 
> to the above request, except that the scope attribute is not present 
> and that the resource-id is replaced with an xpath which points to the 
> individual resource (each in turn).
>
> There is no normative statement about the exact form of this XPath 
> expression, except that it must identify an individual node. Issue #11 
> from the public review concerns this XPath expression. As will be 
> clear, its exact form does not matter, which is the reason the 
> specification does not specify a particular form.
>
> The Axiomatics implementation constructs the expression by referencing 
> the nodes by their order in the tree, so in our implementation the 
> individual requests look like this:
>
>
> <Request
> xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
> xmlns:md="http://www.medico.com/schemas/record"; 
> <http://www.medico.com/schemas/record>>
> <Attributes 
> Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
> <Attribute
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string"; 
> <http://www.w3.org/2001/XMLSchema#string>
> >Julius Hibbert</AttributeValue>
> </Attribute>
> </Attributes>
> <Attributes 
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
> <Content>
> <md:record>
> <md:patient_info>
> <md:name>Bart Simpson</md:name>
> </md:patient_info>
> <md:diagnosis_info>
> <md:diagnosis>
> <md:item type="primary">Gastric Cancer</md:item>
> </md:diagnosis>
> </md:diagnosis_info>
> </md:record>
> </Content>
> <Attribute
> IncludeInResult="true"
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
> <AttributeValue
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"
> >./*[1]/*[1]/*[1]</AttributeValue>
> </Attribute>
> </Attributes>
> </Request>
>
> For each individual request, the XPath expression "./*[1]/*[1]/*[1]" 
> will be different, like "./*[1]/*[1]/*[1]/text()[1]", "./*[1]/*[2]" 
> and so on, covering all nodes selected by the original XPath 
> expression. Other implementations may use another form, but this form 
> is easy to produce since we don't need to track element names, 
> namespaces, etc, just their order.
>
> Somebody mentioned XML overhead before, so I will note that there is 
> no reason to construct each individual XML document in their entirety, 
> rather one can point to pieces of the orignial XML and keep a small 
> chache on the side for the resource-id value. So there is not really 
> any overhead to it. (In XACML 2.0 it is necessary to construct the 
> full <Request> XML since an XPath could be used to refer to any part 
> of it. That is not allowed in XACML 3.0, so the implementation can be 
> efficient.)
>
> A policy could look like this:
>
> <Policy
> xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:cd-1"
> xmlns:md="http://www.medico.com/schemas/record"; 
> <http://www.medico.com/schemas/record>
> PolicyId="urn:FIXME:policy1"
> RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
> <Target/>
> <Rule
> RuleId="urn:FIXME:rule1"
> Effect="Permit">
> <Target>
> <AnyOf>
> <AllOf>
> <Match
> MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
> <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string"; 
> <http://www.w3.org/2001/XMLSchema#string>>Julius Hibbert</AttributeValue>
> <AttributeDesignator
> Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
> DataType="http://www.w3.org/2001/XMLSchema#string"; 
> <http://www.w3.org/2001/XMLSchema#string>/>
> </Match>
> </AllOf>
> </AnyOf>
> <AnyOf>
> <AllOf>
> <Match
> MatchId="urn:oasis:names:tc:xacml:3.0:function:xpath-node-match">
> <AttributeValue
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">
> md:record/md:patient_info
> </AttributeValue>
> <AttributeDesignator
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/>
> </Match>
> </AllOf>
> </AnyOf>
> </Target>
> </Rule>
> </Policy>
>
> This policy will allow Julius Hibbert access to the patient_info 
> section of the medical record, but not the rest. Note how the policy 
> uses an xpath match function, so the exact form of the xpath 
> expression is not significant.
>
> So, there will be results like this:
>
> The md:record/md:diagnosis element:
>
> <xacml-ctx:Result>
> <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision>
> <xacml-ctx:Status>
> <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
> </xacml-ctx:Status>
> <xacml-ctx:Attributes 
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
> <xacml-ctx:Attribute 
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
> IncludeInResult="true">
> <xacml-ctx:AttributeValue 
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[2]</xacml-ctx:AttributeValue>
> </xacml-ctx:Attribute>
> </xacml-ctx:Attributes>
> </xacml-ctx:Result>
>
> The string "Bart Simpson":
>
> <xacml-ctx:Result>
> <xacml-ctx:Decision>Permit</xacml-ctx:Decision>
> <xacml-ctx:Status>
> <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
> </xacml-ctx:Status>
> <xacml-ctx:Attributes 
> Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
> <xacml-ctx:Attribute 
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
> IncludeInResult="true">
> <xacml-ctx:AttributeValue 
> XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 
> DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression">./*[1]/*[1]/*[1]/text()[1]</xacml-ctx:AttributeValue>
> </xacml-ctx:Attribute>
> </xacml-ctx:Attributes>
> </xacml-ctx:Result>
>
> The resource-id is part of the <Result>s since the original 
> resource-id has IncludeInResult="true", see the lines 144-147 in the spec.
>
> So, it is not true that the specification does not have any normative 
> statements of how the XPath "variant" works. Personally I also think 
> the text is quite clear. I can agree that the spec is not good 
> learning material, but I don't think that is the role of standard 
> specification since good learning material needs to be verbose and 
> redundant because one needs examples and different ways to explain the 
> same thing to help learning. But those are qualities which are 
> undesirable in a technical specification, so I would like to keep the 
> text as it is.
>
> Best regards,
> Erik
>
> --------------------------------------------------------------------- 
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail. Follow this link to all your TCs in OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




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