RE: [xacml] Updated policy template wiki

[Jean-Paul Buu-Sao <jean-paul.buu-sao@tscp.org>]

Thank you Danny for clarifying the options. 

I agree with your analysis on options 1 and 2. I do not see a practical case for an AND (conjunctive) on a <Match> attribute, but indeed it does not mean, that there isn't any. Hence I would like to suggest Option 4, with an optional attribute indicating the mode (conjunctive or disjunctive), with default (absence of mode) treated as disjunctive.
This way we keep it real simple for the general case, and yet allow for flexibility.

What do you think?
Jean-Paul

-----Original Message-----
From: Danny Thorpe [mailto:Danny.Thorpe@quest.com] 
Sent: Friday, September 21, 2012 19:08
To: Steven Legg
Cc: Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
Subject: RE: [xacml] Updated policy template wiki

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.

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?

-Danny

Danny Thorpe
Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com 

> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@viewds.com]
> Sent: Thursday, September 20, 2012 5:22 PM
> To: Danny Thorpe
> Cc: Jean-Paul Buu-Sao (jean-paul.buu-sao@tscp.org); xacml@lists.oasis- 
> 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 and
> AttributeSelectors 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>
> >