Policy templates - parameters

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

Danny,

"An example of a feature which would require evaluation of the policy template in the PDP at request time:  If the policy template data format were extended to allow AttributeDesignator or AttributeSelector elements in Parameter definitions alongside simple attribute value elements.  Such constructs cannot be expanded at policy design time (A) nor at import time (B) because their values will vary per auth request"

Thanks for this helpful example. This example suggests that we need to enumerate the various elements that could be parameterized, and the associated required level of support. I provided examples for the first case a) below. Would you have some business examples for the cases that you mentioned, and other cases in mind?

a) AttributeValue (support: static and dynamic reduction) - syntax: see examples https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile%20Examples
b) AttributeDesignator (support: dynamic reduction) - syntax: need example
c) AttributeSelector (support: dynamic reduction) - syntax: need example
d) others?

Thanks,
Jean-Paul Buu-Sao

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

The profile should leave B or C as an implementation decision.  Until such time as a profile names specific features or functions that can only be implemented by evaluating the policy template at request time, policy template handling can be entirely defined by the static reduction process (B).  

The (C) option can be noted as an implementation possibility in the profile text with a requirement that it produce equivalent auth decision results as if the policy template had been reduced to a simple policy per the profile spec. The XACML core spec uses language like this in several places to allow implementations to deviate from the examples as long as they produce equivalent results. 

An example of a feature which would require evaluation of the policy template in the PDP at request time:  If the policy template data format were extended to allow AttributeDesignator or AttributeSelector elements in Parameter definitions alongside simple attribute value elements.  Such constructs cannot be expanded at policy design time (A) nor at import time (B) because their values will vary per auth request.

-Danny

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

> -----Original Message-----
> From: Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
> Sent: Saturday, June 30, 2012 1:21 AM
> To: Danny Thorpe; xacml@lists.oasis-open.org
> Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting
> 
> 1. About the mean to designate each one of the three "forms", I would 
> rephrase your proposal, by considering that we are discussing 
> different "types" of policies: template, data, instance. Hence it follows:
> 
> Policy template, which uses named parameters:
> <Policy  xmlns:pt="urn:policy-template-namespace"  pt:Type="template"
> PolicyId="template1" ... />
> 
> Policy template data, which references a policy template and 
> associates literal data to named parameters:
> <Policy  xmlns:pt="urn:policy-template-namespace"  pt:Type="data"
> pt:PolicyTemplateId="template1" PolicyId="data1"  ... />
> 
> A policy template instance, which results from a reduction of a
> template+data pair:
> <Policy  xmlns:pt="urn:policy-template-namespace"  pt:Type="instance"
> pt:PolicyTemplateId="template1" pt:PolicyDataId="data1"
> PolicyId="instance1" ... />
> 
> 2. About the dynamic data: we are in agreement that this requirement 
> is orthogonal to the requirement of parameterized policies, and I 
> agree to keep it separate from this profile. Should we add this 
> requirement to the list of open issues? So we are now left with a 
> policy templates mechanism that reduces (template + data=instance), 
> with (instance) values only containing literals
> 
> 3. About the reduction mechanism: we need to spell out where the 
> (template + data = instance) reduction can occur:
>    A. At design time in the PAP (meeting the use-case that Hal had in 
> mind, use-case 1 on the Wiki)
>    B. At import time in the PRP (meeting the ITAR/TAA use-case, 
> use-case 2 on the Wiki) -  pro: leaving PDP unmodified, simplifying implementation
>    C. At authorization time in the PDP (meeting the ITAR/TAA use-case, 
> use- case 2 on the Wiki) - pro: allowing more options and 
> opportunities
> 
>   In order to meet the two use-cases we need to consider A and (B or 
> C), and I understand that you favor C
>   The profile must call out the two use-cases (on the Wiki, I will 
> articulate their distinctive features)
>   My question is:
>     a) can we leave B or C as an implementation decision, or
>     b) should the profile be directive on either one?
> 
> Jean-Paul
> 
> 
> -----Original Message-----
> From: Danny Thorpe [mailto:Danny.Thorpe@quest.com]
> Sent: Saturday, June 30, 2012 02:18
> To: Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
> Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting
> 
> >
> > 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))
> 
> I see two ways to implement policy templates:
>   1. Reduce policy template syntax to core-spec policies upon import 
> to the policy repository.  The policy repository and the PDP have no 
> knowledge of policy templates.
>   2. Support policy template syntax directly in the PDP.
> 
> Whenever I refer to the PDP engaging with policy templates, I am 
> referring to the 2nd case.
> 
> I see the value of having option #1 as a least impact path to 
> supporting policy templates.  For my own work, if I were to pursue 
> implementing policy templates I would be more likely to follow option 
> #2 as it inherently provides more options and opportunities.
> 
> >
> > 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.
> 
> If your dynamic literal expansion is orthogonal to policy templates, 
> then it should be considered in a separate discussion and profile.
> 
> I'm not convinced that XACML needs "dynamic literal expansion"; that's 
> what AttributeDesignators are for.  AttributeDesignators are not 
> limited to fetching attributes provided in the auth request - they can 
> fetch data from any data provider available to the PDP context handler.
> 
> Here's how:
> 1. Define an attribute Id to represent your data-to-be-determined-at- 
> evaluation-time (urn:EU-country-codes) 2. Write policy using 
> AttributeDesignators to select that data 3. Configure your PDP context 
> handler with a PIP or DB to provide data values for that attribute Id 
> to the PDP 4. When the PDP evaluates that policy for an auth request, 
> it will discover the AttributeDesignator(urn:EU-country-codes) and ask 
> the context handler to resolve that attributeId into a bag of values.
> 4. Presto, dynamic data.
> 
> The data will always be current because the PDP context handler / PIP 
> / DB have an opportunity to present new country codes on every auth 
> request handled by the PDP.  So when the PDP receives an auth request 
> at 12:01am Jan 1, 2013, it will be up to your DB to return the 28 EU 
> country codes valid at that date.  (If Jan 1 is the activation date)
> 
> Granted, step #3 above does step outside the normative text of the 
> XACML spec, but it is within the overall XAMCL system architecture 
> diagram.  If what you really need is a vendor-independent way to 
> define attribute Ids and their values to work with any conforming PDP 
> implementation, I'd be more inclined to explore a new profile in the 
> PIP area of the diagram than a macro substitution scheme.
> 
> >
> > 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.
> >
> 
> Ok, I'll update the wiki with Match expression transform details.
> 
> -Danny