[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Proposal for changed context node for xpaths in 3.0
Just bumping this up to the agenda for the next TC call. Regards, Erik Erik Rissanen wrote: > All, > > At the previous TC call I promised to write up a concrete proposal for > changing the context node of xpaths in XACML 3.0. This (long) email > provides such a proposal and explains the benefits. > > I do not propose any changes for the XACML 2.0 errata, since this > change would break many 2.0 policies. 3.0 would not lose any > functionality which is available in 2.0, but policies have to be > expressed slightly differently. > > The motivation for the change is to allow for some kinds of > optimizations which are possible when xpaths and attribute designators > are separate and when xpaths are categorized (by attribute category) > so the PDP can say something about where in the request context the > xpath could apply. See the end of this email for a discussion of these > optimizations. > > I would also like to include some normative text which restricts the > form of the xpath. I want to prevent that xpaths may "climb" outside > the <Content> element. There are two reasons for this. > > First, if we do not restrict the xpath, the context node does not > matter much since the xpath could still be used to refer to anywhere > in the resource content and we have not gained anything. > > Second, I don't want policy writers to make any assumptions about the > context in which the XACML request might be in. For instance, if the > request is enveloped in an SAML assertion, the root element of the > document is not the XACML <Request> element, and absolute xpaths will > give different results than if the <Request> element would have been > the root element. One way for an implementation to solve this would be > to copy the whole <Request> into its own document so the <Request> is > always the document element, but this costs CPU cycles. I would like > to avoid this, so we should write the spec so it is clear that PDP > don't need to do this. > > I propose the following changes (references to wd 5 of the 3.0 core > spec): > > ---8<--- Begin proposal > > Section 5.29 Element <AttributeSelector>: > > -> Add a new XML attribute to the <AttributeSelector> element: > > Category [Required] > This attribute SHALL specify the attribute category of the > <Content> element where the xpath is applied. > > -> Change the description of the RequestContextPath xml attribute. It > is currently: > > RequestContextPath [Required] > An XPath expression whose context node is the <Request> element. > There SHALL be no restriction on the XPath syntax. See also Section 5.4. > > It should be changed to: > > RequestContextPath [Required] > An XPath expression whose context node is the <Content> element of > the attribute category indicated by the Category attribute. There > SHALL be no restriction on the XPath syntax, but the XPath MUST NOT > refer to or traverse any content outside the <Content> element in any > way. See also Section 5.4. > > > Section 7.2.1 Structured attributes > > This section currently contains these two alternatives for using > structures types: > > 2. An <AttributeSelector> element MAY be used to select the > contents of a leaf sub-element of the structured data-type by means of > an XPath expression. That value MAY then be compared using one of the > supported XACML functions appropriate for its primitive data-type. > This method requires support by the PDP for the optional XPath > expressions feature. > 3. An <AttributeSelector> element MAY be used to select any node in > the structured data-type by means of an XPath expression. This node > MAY then be compared using one of the XPath-based functions described > in Section A.3. This method requires support by the PDP for the > optional XPath expressions and XPath functions features. > > -> Change the beginning of both these these paragraphs to the > following: "The structured attribute MAY be made available in the > <Content> element of the appropriate attribute category and "... > > > Section A.3.14 XPath-based functions > > -> For each of the three xpath based functions, add one additional > argument of type anyURI. The following text explains this argument: > "This argument indicates the attribute category of the <Content> > element where the xpath expression(s) are applied." > > -> In the first paragraph of section A.3.14 replace "The <Request> > element is the context node for every XPath expression" with "Each > function takes an attribute category as an argument. The <Content> > element in that attribute category is the context node of the xpath > expressions." > > -> At the end of the first paragraph of section A.3.14 write: "The > xpaths MUST NOT refer to or traverse any content outside the <Content> > element in any way." > > > -> Allow <Content> in the <PolicyIssuer> element. This is needed to > allow for structured attributes with attribute selectors on delegates. > > Currently it is like this: > > <xs:element name="PolicyIssuer" type="xacml:PolicyIssuerType"/> > <xs:complexType name="PolicyIssuerType"> > <xs:sequence> > <xs:element ref="xacml:Attribute" minOccurs="0" > maxOccurs="unbounded"/> > </xs:sequence> > </xs:complexType> > > There is no <Content> element in there, although the policy issuer > essentially is a special category of request attributes. It should be > like this: > > <xs:element name="PolicyIssuer" type="xacml:PolicyIssuerType"/> > <xs:complexType name="PolicyIssuerType"> > <xs:sequence> > <xs:element ref="xacml:Content" minOccurs="0"/> > <xs:element ref="xacml:Attribute" minOccurs="0" > maxOccurs="unbounded"/> > </xs:sequence> > </xs:complexType> > > The descriptive text for the new <Content> element will refer to the > same place as the description of the <Attributes> element. > > > -> Also update the examples accordingly: use relative xpaths from the > <Content> element and add the Category attribute in attribute selectors. > > -> Also update the context node of the xpath based functionality in > the multiple and hierarchical resource profiles. I have not looked > into the details yet, but from my memory of the profiles, the changes > should be just to change the context node in a couple of places and > insert the text which restricts the xpath to the content element. > > ---8<--- End proposal > > > The following is not intended as part of the spec document, but > explains how 3.0 will retain the equivalent functionality as XACML > 2.0. (I have extracted the text from a previous email I sent on the > topic.) > > Assume that someone has defined a structured attribute type describing > a book, and we have a request like this: > > <Request> > <Attributes Category="resource"> > <Attribute AttributeId="resource-id" DataType="book"> > <AttributeValue> > <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book> > </AttributeValue> > </Attribute> > </Attributes> > ... > </Request> > > Currently an attribute selector can refer to the isbn number like this: > > <AttributeSelector > RequestContextPath="Attributes[@Category="resource"/Attribute[@AttributeId="resource-id"]/AttributeValue/Book/ISBN/text()"/> > > > (The path is paraphrased and not strictly correct xpath, but you get > the idea.) > > Now assume that we do not allow reference to the <Attribute> element > with the attribute selector and make the <Content> the context node. > It would no longer be possible to access the isbn number of the book > with an attribute selector. However, the same effect can be achieved > by rewriting the policy and the request. > > The alternative is to place the structured data type in the <Content> > element (note that the <Content> element is available in all > categories, not just the resource, in 3.0): > > <Request> > <Attributes Category="resource"> > <Content> > <Attribute AttributeId="resource-id" DataType="book"> > <AttributeValue> > <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book> > </AttributeValue> > </Attribute> > </Content> > </Attributes> > ... > </Request> > > This can the be referenced by an attribute selector. And since the XML > is the same, no loss of functionality occurs. > > Of course it will still be possible to define and implement custom > functions which can be used via attribute designators, as can be done > in 2.0. > > > The text below gives some more detail about the optimizations which > have difficulties because of the current behavior. At least the > following problems with optimizations occur currently: > > - Parsing the request context into a some form of optimized/indexed > form for attribute designators is possible, but because the xpath can > refer to anything in the request XML, the request has to be also > retained in XML form unless a custom xpath implementation is used. > > This is an issue if the context handler finds attributes from an > external source. In this case either the request XML has to be updated > with any attribute which the context handler could possibly find as > soon as we reach the first xpath function, or we ignore this. If we do > the updating, then this is a performance issue. If we ignore the > problem, the behavior of the xpath functions becomes implementation > specific. (Unless the spec explicitly says that this is how it should > be like, that is, only the initial XML can be referenced with xpaths. > I haven't searched the spec for it, but I don't recall ever seeing a > statement like that. If it says so, let me know.) > > - A special case of the above is that administrative requests have to > be constructed in XML form during reduction. > > - Partial evaluation becomes less useful since no xpath based function > can be evaluated partially currently. > > However, if xpaths would be restricted to the <Content> elements and > all xpath functions would have an explicit marker for the category, we > could introduce partial evaluation of xpath functions at the category > granularity. (For instance, if an xpath refers to the subject and the > subject is part of the partial request, then we can run that xpath, > but if the xpath refers to the resource and the resource is not in the > partial request, we cannot run that xpath.) > > I think partial evaluation is a very useful function and I think it is > worth making the spec so it can be implemented efficiently. > > - The multiple resource profile becames more complex and less > efficient to implement. > > The multiple resource profile has a form of multiple request with > repeated <Attributes> elements, like this: > > <Request> > <Attributes Category="Subject"> Alice </Attributes> > <Attributes Category="Resource"> A </Attributes> > <Attributes Category="Resource"> B </Attributes> > <Attributes Category="Resource"> C </Attributes> > <Attributes Category="Resource"> D </Attributes> > </Request> > > This is the same as running four separate requests for the four > resources, with Alice as the subject in all these requests. > > If xpaths can only refer to inside the <Content> in the <Attributes> > element, each Attributes element can be parsed individually into the > processing form of the implementation and these objects can be > combined individually into individual requests. > > If xpaths can refer to anywhere in the request, for each individual > request, we have to construct a brand new XML representation as well. > > There is a similar issue in the "scope" based multiple resource > profile. In this case the resource-id attribute of the initial request > has to be replaced with another resource-id for the individual > requests. This can probably be done fairly efficiently by just > changing the id in the internal representation in the PDP when running > the individual requests. With wide open xpaths, the XML representation > has to be changed as well. Well, maybe this is not a big deal? > Changing this value in a DOM is probably not very inefficient. But > modifying the DOM could introduce synchronization issues in a > concurrent implementation, or the whole DOM would have to be > replicated, which would be inefficient. > > Then there is a really obscure problem, which I am not sure we should > worry about. This is not really an optimization problem, but more a > matter of details in conformance to the spec. The multiple resource > profile describes that new requests are to be generated based on the > original multiple request. This raises the issue of how whitespace in > the new request relates to the whitespace in the original request. > (The same issue occurs in generation of administrative requests during > reduction as well.) I don't think anyone of us thinks of whitespace as > being significant in XACML, but it is significant in xpath, so in the > strict sense, since we use xpath, there is an ambiguity here. But then > it would be pretty stupid to write an XACML policy with an xpath which > refers to whitespace. :-) If we restrict xpaths to the inside of the > content element, we don't need to worry about whitespace since we > would never modify or generate the content element in the PDP > processing. (Personally, it just bugs me that when I implement the > spec, there is this ambiguity in there. :-)) > > Best regards, > Erik > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and 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]