RE: [xacml] Proposed Agenda for 28 June TC Meeting

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

Thank you Danny for improving the definitions and requirements. I meant to notify the group of this new page after some initial polishing, that you provided. So I guess now is time to continue developing this Wiki (and still notify the group of changes on it)

https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile

There are still two aspects that concern me though:
a) You keep referring to the PDP as the component doing the policy template reduction, where I assumed that this component can leave outside of the PDP, for instance to allow a zero impact on existing PDP. This is the reason why I introduced this Policy Template Engine, that can physically reside in the PDP but could be outside, such as in the PRP or PAP; and yes, I suggest that reduction yields a core-spec policy, with the only caveat that this core-spec contains information on the sources of the reductions (this info does not affect the core evaluation for authorization, and is just needed for change-management))

b) We are in agreement on the two distinction of static vs. dynamic reduction; however I assumed that the dynamic reduction is orthogonal to policy templates: it could very well be  a capability that makes sense outside of a policy template, as a substitute for any literal value in existing (non templatized) policies. I think that this is healthier to keep this dynamism separate of policy templates, as dynamic resolution has, by definition, to occur in the PDP, whether the policy has been reducted or not

I agree that two approaches are possible (PTE on the PAP/PRP, or on the PDP), but if we make the two capabilities of reduction and dynamic literal expansion independent, then reduction can use either approach, whereas dynamic literal substitution must be implemented in the PDP. Again, and this is a question: does dynamic literal expansion a capability that can exist outside of templates? I think yes but need confirmation. Example of a dynamic literal expansion: the string "$EU" (or whatever makes sense) is expanded, at authorization time, to a bag that currently (in 2012) contains 27 literal country codes.

Thank you for your detailed analysis on what must happen on reduction of Match expressions. I let you report these findings in a new section of the Wiki, such as "Technical implications" or equivalent.

Jean-Paul


-----Original Message-----
From: Danny Thorpe [mailto:Danny.Thorpe@quest.com] 
Sent: Friday, June 29, 2012 20:50
To: Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting

Jean-Paul,

I found the new wiki page you created (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile). I can help copy data points from this conversation over to the wiki page as we go.

> a. "I can see in your examples that the named parameters are injected 
> as AttributeValue elements, which will satisfy XACML schema 
> requirements but will not enable correct evaluation unless the PDP has 
> specific knowledge of the meaning of the ParameterId attribute on the AttributeValue."


> [JP] You said "the PDP" but I assume you meant the 
> policy-template-data- generator component, that IMO would be more in 
> the area of PAP or PRP, than PDP. So the suggested semantics is simply 
> based on AttributeValue elements name matching between the ones of the 
> policy-template and the ones of the policy-data, and this specific 
> knowledge would be restricted to this one (new) component, with no 
> impact on any other
>

I think my comment crossed wires. ;>  I was observing that the proposed syntax for using parameters in a policy template (using an AttributeValue with a special ParameterId attribute) will produce a policy that will pass Xacml 3.0 core schema validation.  That's kind of nifty, but something more has to happen before the policy template can be evaluated to produce auth decisions:  either the PDP needs to understand policy template syntax and semantics, or the policy template needs to be reduced to core-spec policy syntax.

Having a formal definition of the transform needed to reduce a data+policy instance to core-spec policy syntax will be useful to illustrate how the policy template relates to core-spec policy definitions and to provide a lower-cost path for adoption for implementers.  Implementers can choose to take a minimum effort path by transforming data+policy instances at import, or with greater effort and code modification they can choose to integrate knowledge of policy templates into the PDP core evaluator.

There is a significant difference in capabilities between these two approaches.  The reduce-at-import approach is a static representation of the policy template built well before auth request evaluation time. The integrated-into-PDP-evaluator approach is capable of dynamic evaluation of named parameters in the context of an auth request.  This would address your point about parameter data changing over time.

If we want to include some aspect of dynamic evaluation of named parameters in this profile, we should make a clear distinction between static import and dynamic evaluation and segregate features by these modes.  It will be difficult to define dynamic evaluation of named parameters in a static reduced-at-import policy.  Perhaps the policy template profile should contain a static import section and a dynamic evaluation section to discuss the capabilities and limitations of each.

> b. It should be possible to transform (reduce) parameterized policies 
> to traditional policies, so that the PDP does not need special 
> knowledge to evaluate parameterized policies correctly.
> [JP] Exactly so, modulo the fact that, as said on 6. the reduced 
> policies retain the information of their sources

The generated / reduced policy will need to have a reference back to the policy template and data+policy instance.

Which raises a question: How do we distinguish between these three forms of policy?  There is no top-level marker in the policy template <Policy> to indicate right away that this is a policy template.

Perhaps something like a Mode (or Form?) attribute:

Policy template, which uses named parameters:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="template"  PolicyId="template1" ... />

A data+policy instance, which references a policy template and defines data for named parameters:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="instance"  pt:PolicyTemplateId="template1" PolicyId="instance1"  ... />

A policy generated by reducing a data+policy instance:
<Policy  xmlns:pt="urn:policy-template-namespace"  pt:Mode="reduction" pt:PolicyInstanceId="instance1" pt:PolicyTemplateId="template1"  PolicyId="reduction1" ... />

Including the template id on the reduction is a little bit redundant since that could be found by looking up the policy instance, but worth the convenience I think.

> 
> c. Parameterized policy reduction would need to rewrite Match 
> expressions that reference a named parameter to produce one Match 
> expression per parameter data item and the Matches combined under an 
> OR operator
> (AnyOf) because the attribute value of a Match expression cannot be a 
> bag of values.
> [JP] So you are saying that the policy-template-data-generator 
> component would potentially to expression rewrite, not only bag 
> expansion. Seems to be a derived technical requirement
>

Correct - bag expansion alone of named parameters in reduction will produce invalid Match expressions.
 
Template:
<Match ...>
  <AttributeValue parameterId="country" ... />
  <AttributeDesignator .../>
</Match>

Reduced by substituting bag for named parameter:
<Match ...>
  <AttributeValue ...>US</AttributeValue>
  <AttributeValue ...>FR</AttributeValue>
  <AttributeDesignator .../>
</Match>

Or?

<Match ...>
  <Apply functionId="string-bag">
	<AttributeValue ...>US</AttributeValue>
  	<AttributeValue ...>FR</AttributeValue>
  </Apply>
  <AttributeDesignator .../>
</Match>
 

Neither of those are valid Match expressions.

Reduction must replicate the Match expression under an AnyOf to preserve Match's single-value first parameter requirement:

<AnyOf>
  <Match ...>
    <AttributeValue ...>US</AttributeValue>
    <AttributeDesignator .../>
  </Match>
  <Match ...>
    <AttributeValue ...>FR</AttributeValue>
    <AttributeDesignator .../>
  </Match>
</AnyOf>
  

> d. If a Match expression referencing a named parameter resides at the 
> nesting limit of a Target expression, the expression resulting from 
> parameter reduction will exceed the Target expression's limit of 3 nesting levels.
> Reduction should fail.  Caveat policy writer: Keep your Matches at 
> level 1 or 2 in parameterized policies.
> [JP] OK, you are establishing a requirement on a) the policy template 
> authoring tool, as well as b) on the policy-template-data-generator 
> that surely must produce an exception should the case arise
> 

Yes.

> e. In Condition expressions, your sample code only uses named 
> parameter AttributeValues inside bag constructors.  I suggest making 
> this a required pattern of use to simplify parameter reduction. Though 
> it's a bit wordy to author, it works well to simplify reduction tasks. 
> Reduction need only replicate the AttributeValue in-place for each 
> parameter data item, without modifying any of the condition expression 
> around it. (Nice!) Match expressions would be the only exception to this requirement.
> [JP] Confirming that it's expansion in most cases, but for Match 
> expressions, as you said above

Yes.

Strictly speaking, though, the named parameter doesn't expand to a bag, it expands to zero or more  <AttributeValue> elements.  In condition expressions, the policy template author must place the named parameter within a bag constructor.  

This is solely to simplify the profile so we don't have to define a transform to rewrite condition expressions where a named parameter is used as an argument to a function that is expecting a single value.  

-Danny