[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Updated policy template wiki
Hi Danny, On 22/09/2012 3:08 AM, Danny Thorpe wrote:
Steven, You're right, the expansion of <Match> elements has to propagate to its container to preserve the Boolean relationship to sibling <Match> elements of the same AllOf container. The question of conjunctive vs disjunctive is a more serious problem. As currently spec'd, there's no way for a policy writer to indicate whether they want parameter expansion to produce a disjunctive set (OR), or a conjunctive set (AND) when the parameterized <AttributeValue> is used in a <Match> expression. This isn't a problem for condition expressions because the policy writer can use the parameterized attribute as an argument to AnyOf or AllOf functions as needed, so simply replacing the parameterized <AttributeValue> element with a set of <AttributeValue> elements shouldn't present a problem. The fixed structure of the <Target> expression makes it difficult to express a policy writer's intent of whether parameter substitution should be performed as an AND or as an OR operation over the list of injected values. We have a few options to deal with this issue: 1. Prohibit template parameters in <Match> elements 2. Require template parameters used in <Match> elements contain exactly one value 3. Support only disjunctive combination of substituted values when rewriting a <Target> expression 4. Add syntax to allow the policy writer to indicate whether they want the parameter values used conjunctively or disjunctively in each parameterized <AttributeValue>. Option 1 severely restricts the usefulness of policy templates.
Option 2 seems impractical. The writer of the policy template data would need to know how the parameter will be used by policies. Brittle.
The writer of the policy template data currently has this issue with respect to parameters in conditions. For example, if the parameter is one of the two arguments to the string-equal function, then the parameter can only validly have one value. Option 2 also seems too restrictive.
Option 3 leaves out the conjunctive use case. Is this acceptable? Possibly. If we consider conjunctive use of parameterized <AttributeValue>s in condition expressions to be an (allowed) aberration, I guess we could declare/assert that parameter values are handled disjunctively across the board. The provided policy template use cases appear to be of a disjunctive mindset. Option 4 is doable, but if we can eliminate the need for supporting the conjunctive case, we should. Jean-Paul, what do you think of these options?
I don't have an opinion on whether conjunctions should or shouldn't be allowed. Jean-Paul's proposal of an optional attribute indicating the mode is fine by me. Regards, Steven
-Danny Danny Thorpe Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com-----Original Message----- From: Steven Legg [mailto:firstname.lastname@example.org] Sent: Thursday, September 20, 2012 5:22 PM To: Danny Thorpe Cc: Jean-Paul Buu-Sao (email@example.com); firstname.lastname@example.org- open.org Subject: Re: [xacml] Updated policy template wiki Hi Danny, On 21/09/2012 4:25 AM, Danny Thorpe wrote:I've updated the policy template wiki (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile) with text about required Match expression rewriting in parameter substitution and optional use of AttributeDesignators andAttributeSelectors in Parameter data in dynamic policy template reduction implementations. With regard to the Match expression rewriting, the Match element is already, of necessity, a child of an AllOf element that is a child of an AnyOf element. In the general case there may be other Match element children of the AllOf element and other AllOf children of the AnyOf element. It seems to me that the rewriting rule should be to create a duplicate of the AllOf element (with all of its Match children) for each parameter value, substituting the parameter in the particular Match element being expanded with the corresponding parameter value. The resulting AllOf elements would replace the original AllOf element that contains the Match element with the parameter being expanded. Apart from having its list of AllOf children expanded, the AnyOf element would be unchanged. If an AllOf element contained multiple child Match elements with parameters, then the effect would be to take the cross-product of the sets of parameter values. This assumes that the desired effect is a disjunction of the parameter values. If a conjunction is desired, then the Match element would be duplicated within the single AllOf element that contains it, with each duplicate taking a different parameter value. The AllOf element and its parent AnyOf element would otherwise be unchanged. Incidentally, I find the terminology section confusing. Policy template instance and policy template data seem to be the same thing and are used interchangeably. Regards, Steven-Danny *Danny Thorpe * Product Architect | | *Quest Software*- /Now including the people and products of BiTKOO/ | www.quest.com <http://www.quest.com>