Re: [xacml] Summary of the 3 proposed syntaxes for Policy Template

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

Jean-Paul,

On 17/10/2012 7:52 PM, Jean-Paul Buu-Sao wrote:
> Erik
>
> The core specification says that “The <AttributeDesignator> element retrieves a bag of values for a named
> attribute from the request context”. Hence the scope for the resolution of the named attributes cannot be
> limited to the scope of the container <Policy> element alone, but is the one of the whole request context.
> It follows that you cannot compose a <PolicySet> with multiple parameterized <Policy>, in the case of name
> conflicts, unless there is some kind of naming convention introduced.
>
> For example, the <PolicySet> below contains two <Policy> that are parameterized. There is a name-clash in
> the  named parameters “Organizations”:
>
> <PolicySet PolicyId="urn:example:set1" … >
>
> <Policy PolicyId="urn:example:template1" … >
>
> ...
>
> <Condition>
>
> ...
>
> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="Organizations" MustBePresent="true">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; MustBePresent="true"/>
>
> </Apply>
>
> ...
>
> </Condition>
>
> ...
>
> </Policy>
>
> <Policy PolicyId="urn:example:template1" … >
>
> ...
>
> <Condition>
>
> ...
>
> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="Organizations" MustBePresent="true">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; MustBePresent="true"/>
>
> </Apply>
>
> ...
>
> </Condition>
>
> ...
>
> </Policy>
>
> </PolicySet>
>
> One must introduce a naming convention on the named parameters to establish the correct scope, such as:

Yes, if you are considering the case where there is only one policy template
data set for each policy template and normal PDP processing is being used
to evaluate the template. In this case we are not really talking about
templating at all. In the more general case where there can be any number of
policy template data sets for each policy template we have either a policy
template engine or dynamic template reduction (which is not normal PDP
processing). There is no conflict in this case because the policy template
data sets are bound to specific templates via the template's identifier.
The policy template engine uses the parameter values from the policy template
data sets bound to the template it is currently processing.

Also, globally unique names for parameters isn't enough to legitimize the use of
attribute designators for parameters. Consider this excerpt from section 7.3.5
of the latest core specification:

    "Regardless of any dynamic modifications of the request context during
     policy evaluation, the PDP SHALL behave as if each bag of attribute
     values is fully populated in the context before it is first tested,
     and is thereafter immutable during evaluation. (That is, every subsequent
     test of that attribute shall use the same bag of values that was initially
     tested.)"

If there is more than one policy template data set for the same policy template,
then this rule will be broken. That's not a showstopper because parameters are a
different beasty to attribute designators, even if the syntax is the same, but
it is ugly to be saying that there is a particular use of the syntax for a
new purpose that violates some of the rules of its original purpose.

If the parameter names are globally unique, then consider that a template may
contain a parameter that belongs to a policy template data set that is bound
to an entirely different policy template. That has some interesting implications,
which I can discuss if you want to go there. I can also imagine several different
ways to reduce your example with two embedded policy templates.

Regards,
Steven

> <PolicySet PolicyId="urn:example:set1">
>
> <Policy PolicyId="urn:example:template1">
>
> ...
>
> <Condition>
>
> ...
>
> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="urn:example:template1:Organizations" MustBePresent="true">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; MustBePresent="true"/>
>
> </Apply>
>
> ...
>
> </Condition>
>
> ...
>
> </Policy>
>
> <Policy PolicyId="urn:example:template2">
>
> ...
>
> <Condition>
>
> ...
>
> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="urn:example:template2:Organizations" MustBePresent="true">
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
> AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"; MustBePresent="true"/>
>
> </Apply>
>
> ...
>
> </Condition>
>
> ...
>
> </Policy>
>
> </PolicySet>
>
> Would you confirm this analysis?
>
> Thanks,
>
> Jean-Paul
>
> *From:*xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] *On Behalf Of *Erik Rissanen
> *Sent:* Friday, October 12, 2012 10:02
> *To:* xacml@lists.oasis-open.org
> *Subject:* Re: [xacml] Summary of the 3 proposed syntaxes for Policy Template
>
> Jean-Paul,
>
> Thanks for the summary. I might add that for the AttributeDesignator approach, I did not intend to do
> substitution in target <Match> elements. My point is to stay within the current XACML 3.0 core schema, and
> avoid any extra processin steps. Thus it would be a "con" to this approach that any targets need to be
> rewritten into conditions using the on-permit-apply-second algorithm.
>
> Best regards,
> Erik
>
>
> On 2012-10-11 15:39, Jean-Paul Buu-Sao wrote:
>
>     Greetings
>
>     There has been an intense and healthy discussion around the syntax for Policy Templates recently, thanks
>     to Danny Steven and Erik. I thought that I should summarize the various proposals on the Wiki:
>
>     https://wiki.oasis-open.org/xacml/Policy%20Template%20Syntactic%20Options
>
>     Danny, Steven, Erik, please apologize if I missed on of your points. I still have to double check that
>     OOI have not forgotten anything against the email thread (I fact I have, but will correct before today
>     close of business).
>
>     Thanks,
>
>     Jean-Paul