Re: [xacml] Updated policy template wiki

[Steven Legg <steven.legg@viewds.com>]

Danny,

On 5/10/2012 5:10 AM, Danny Thorpe wrote:
> When the original proposal for policy templates was brought forward, I noted that simply replacing a single
> AttributeValue element with a list of values from the policy template <Parameter> would fail in <Match>
> expressions, since <Match> is very explicit about one value, one designator/selector.  I offered a transform
> to help produce valid match expressions.
>
> AttributeDesignator does provide similar “insert-multiple-values-here” operations to the policy template
> substitution behavior, but I believe the suggestion of policy parameterization came up because of situations
> in which AttributeDesignator cannot be used. Comparing an  attribute against a static list of test values
> (specific to an organization or location and applied to a generic policy), for example, is a many-to-many
> comparison, but cannot be expressed in a <Match> element.
>
> As we discussed on the TC call today, we’re finding more difficulties with parameter substitution the deeper
> we dig. Steven Legg noted in an earlier email that some Xacml functions that take single <AttributeValue>
> won’t work if multiple values are dropped in to replace the <AttributeValue>. This means some sort of
> expression transform will be necessary in condition expressions as well to move policy templates forward.

Instead of doing that, I was thinking of having a way for the policy template
writer to indicate whether the parameter was intended to be single-valued or
allowed to be multi-valued (i.e., a bag). Although that can be achieved with an
extra XML attribute on <AttributeValue>, my preference would be to define two
new elements, say <ValueParameter> in a substitution group for <AttributeValue>,
and <BagParameter> in the substitution group for <Expression>, both with
ParameterId and DataType XML attributes. The <ValueParameter> element could be
used anywhere an <AttributeValue> can appear, including in a <Match> element,
while <BagParameter> could be used anywhere that an expression evaluating to
a bag is allowed.

Not surprisingly, <ValueParameter> is always replaced with a single <AttributeValue>
and <BagParameter> is always replaced by a type-bag of values, possibly empty.

Whatever way it is indicated, making it explicit whether a parameter is single-valued
or multi-valued makes it easier to do static checking of the policy template,
makes it clearer to the policy template data writer what is expected for each
parameter, and avoids any fancy transforms in conditions (for most practical
purposes). The on-permit-apply-second combining rule compensates for not allowing
bag parameters in targets, so we can avoid complicated transforms there as well.

Regards,
Steven

> In light of these increasing complexities and challenges, I’m beginning to agree with you that perhaps the
> policy template use case can better be addressed using the existing <AttributeDesignator>.
>
> This would mean:
>
> 1.Giving up parameterization behavior in <Match> expressions and moving that logic into conditions using
> <AttributeDesignator> to reference an attribute ID representing the parameterization data.
>
> 2.Moving parameterization data from a static policy generator step to a PIP to fill <AttributeDesignator>
> references to a particular attribute ID with parameterization data in the PDP at auth request evaluation time.
>
> Using <AttributeDesignator> instead of policy templates does impact the use case quite a bit because
> populating PIP data is not part of the Xacml spec.  Policies could be shared between organizations per the
> use case, but how the parameterization data is applied to those policies would become a vendor-specific
> implementation detail.
>
> I can see the attraction of parameterizing policies to allow up-front synthesis of specific policies, but as
> we say “the devil is in the details.” The details are winning. :/
>
> -Danny
>
> *Danny Thorpe *
>
> Authorization Architect
>
> Dell | Identity & Access Management, Quest Software
>
> Quest Software is not part of Dell.
>
> *From:*xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] *On Behalf Of *Erik Rissanen
> *Sent:* Thursday, October 04, 2012 4:42 AM
> *To:* xacml@lists.oasis-open.org
> *Subject:* Re: [xacml] Updated policy template wiki
>
> All,
>
> I still fail to see why this is useful.
>
> If you take a policy template, and replace each <Parameter> with an appropriate <AttributeDesignator>, then
> you get a regular XACML policy, and the PEP/PDP can "fill in" the "template" at runtime using normal XACML
> attributes.
>
> Why do we need a new standard? In particular I would be opposed to "implementation option C", that is a PDP
> would construct the policy from the template at runtime. That's lots of heavy machinery for no gain.
>
> Best regards,
> Erik
>
> On 2012-09-20 20:25, 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.
>
>     -Danny
>
>     *Danny Thorpe *
>
>     Product Architect | | *Quest Software*- /Now including the people and products of BiTKOO/ |
>     www.quest.com <http://www.quest.com>