[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Walkthrough of multiple profile (related to public reviewissue #11)
Paul, I think the main issue here is that the XACML Request is described as an abstract concept, not a wire protocol. In most implementations there would be 1. An initial access request defined with the XACML <Request> schema. (Possibly embedded in some transport unit.) 2. A context handler which can potentially fill in additional attributes. The issue here is that the XACML spec is more like: 1. A full XACML request exists in an abstract form, which is the combined result of the PEP and the context handler. In other words, the core XACML spec does not differentiate between an initial request and stuff that the PEP is not aware of, with regard of the processing model. It hasn't been a problem in the past since the request has been fully hidden to the PEP, but now with IncludeInResult, parts of it are reflected back, which introduces the distinction between an initial request and a full context handler augmented request. Whatever the spec says on this matter is purely by accident, since we have not discussed this distinction, and now is time to fix this. So, we should say something on the issue. The model which would place the least burden on the implementation would be to explicitly say that only the attributes sent by the PEP must be reflected back, but I am not sure that is the most useful mode. I don't understand your "key attribute" proposal. Could you elaborate on it? How is this different from setting IncludeInResult on several attributes in the request? Thanks, Erik Tyson, Paul H wrote: > The conceptual model for transforming xpath-selector resource-ids into > individual node ids is sufficiently specified. I just didn't see > where it said what form of these individual ids should be returned in > the xacml Response. But I guess that is specified in the core > spec under "IncludeInResult". > > However, the core spec is not very helpful here. A strict reading > would say the PDP must only return attributes specified in the > original request--not those added by the context handler. Suppose the > original request included one "role" attribute known to the PEP, > with IncludeInResult=true. The PDP evaluates policies with additional > "role" attributes found by the PIP. Should the result include just > the original role attribute value, or all the values in the decision > context? Does "IncludeInResult" mean "include all values of this > attribute type from the decision context" or "include just this > attribute value from the original request"? The MR profile defines > "IncludeInResult" to mean "whatever value the implementation uses to > describe an individual node using xpath" (for xpath resource-ids). I > can see this causing interoperability problems. > > On a slightly different, but related topic, I think the ability > to specify key attribute types would make it easier to implement and > use the multiple request profile. The original request could declare > the set of key attribute ids for each decision, and the PDP would have > to include those Attributes in each individual Result. This would be > much more flexible and precise than "IncludeInResult". > > --Paul > > > ------------------------------------------------------------------------ > *From:* Erik Rissanen [mailto:erik@axiomatics.com] > *Sent:* Friday, October 09, 2009 09:50 > *To:* XACML TC > *Subject:* [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";> > <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"; > >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";>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";> > <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"; > >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"; > 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";>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"/> > </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]