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: [xacml] Updated policy template wiki

Hi Danny,

On 22/09/2012 3:08 AM, Danny Thorpe wrote:

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.



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-
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

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
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



*Danny Thorpe *

Product Architect | | *Quest Software*- /Now including the people and
products of BiTKOO/ | www.quest.com <http://www.quest.com>

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