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

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

Danny,

You have put a lots of thoughts onto the proposal. Your questions are definitely forcing the formalization of requirements. I was wondering if it would make sense to use the Wiki, whether in complement (to report the requirements) or a replacement to the email thread.

Hal, what do you recommend we should do? For the time being I try to deliver replies to each of your questions below:

1. Must the parameter data be only a bag of single-value elements?
[JP] Single literal elements. However there are actual use-cases where one-level bag of bag is desirable (see your question 2)

2. Must the parameter data be constant / literal values?  Or are attribute references allowed?  (I assume literals only)
[JP] Literal in most cases. However I can see cases where references are useful, assuming these references can be resolved say by the PIP. Example: a parameter data is a bag of countries, that are mostly expressed as constant {"US", "FR"}; in addition some literal, via naming convention, would designate a bag that needs to be expanded, for example in {"US", "$EU"} where "$EU" refers to the list of EU countries. One problem that I can see is that the "simple" mechanism that we are envisioning (that is: policy template + parameter data resolution at administration time) requires the expansion to be performed at administration time, generating actual literal values. In 2012 "$EU" resolves a bag of 27 literals, that will be off one country at least ("HR" = Croatia) in 2013. So maybe a dynamic bag expansion capability, orthogonal to policy-templates, would be a goodness.

3. Must the values in a given parameter be of the same data type?
[JP] Yes

4. Is there ever a situation in which the parameter data needs to be evaluated in a certain order?
[JP] No. They are bags, as you say, and retain the bag semantics

5. ParameterId values are always constant literal values, right? (let's not go down the meta-meta path...)
[JP] Yes, those are identifiers that need to match between the policy template and the policy data. What happens if there is no match must be defined (i.e. empty bag or exception)

6. Is the intention that these data+policy instances could be instantiated (generating "flat" XACML 3.0 core conforming policies) when imported into a policy repository? If so, then code changes needed to support a parameterized policy profile could be limited to the point of import, minimizing code impact on the rest of the system
[JP] Yes, I understand that this helps to keep it simple and implementable. Now I can see use cases where it is desirable to regenerate the flat instances: when policy change (and they do in A&D), then consequently policy templates change. It is required that a generated flat policy retains the information that it has been generated from a given template and a given policy data, so in case either change, some application TBD has enough information to trigger a re-generation

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

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

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

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

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

f. One of your XACML samples in the document shows an AttributeValue following an AttributeDescriptor in a Match expression.  Is that a hand-written example?  I seem to recall the 3.0 core spec requires the AttributeValue always appear before the AttributeDesignator/Selector.
[JP] Yes it is hand-writtten, for the time being. I'll update the example at next pass to conform. Thanks for the catch.

Regards,
Jean-Paul Buu-Sao

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

The policy template proposal appears to be a means to bundle data with a policy, producing a data+policy instance.  The data is constant for the lifetime of the data+policy instance.

This could be achieved using existing attribute designators, pushing the data binding off into the context handler or beyond. However, I can appreciate that identifying/specifying the data needed in scope to evaluate a policy with the same effect as a data+policy instance would be cumbersome at best.

Care must be taken that the data+policy instance has a policy id that is unique and not to be confused with the policy id of the policy template, because different data bound to the same template makes for a completely different set of policy logic.

Questions:

1. Must the parameter data be only a bag of single-value elements?  Meaning, a parameter cannot consist of a bag of bags.  (I assume bag of single-values only) 2. Must the parameter data be constant / literal values?  Or are attribute references allowed?  (I assume literals only) 3. Must the values in a given parameter be of the same data type? I hope the answer is yes. :> 4. Is there ever a situation in which the parameter data needs to be evaluated in a certain order?  I'm not saying this should be supported, but it would be worth reminding readers that bags do not imply order of evaluation.
5. ParameterId values are always constant literal values, right? (let's not go down the meta-meta path...) 6. Is the intention that these data+policy instances could be instantiated (generating "flat" XACML 3.0 core conforming policies) when imported into a policy repository? If so, then code changes needed to support a parameterized policy profile could be limited to the point of import, minimizing code impact on the rest of the system.

Certainly, an implementation could implement direct knowledge of parameterized policies throughout the system to minimize storage requirements (instantiate the date+policy on demand in memory), but it would be useful to note whether supporting parameterized policies could be fully implemented by "just" reducing the parameterized policies to traditional policies at the point of import.  (Assume one-way import. The repository is not required to synthesize the original parameterized policy representation)

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.

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.

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.

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.

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.

Trivial nitpick:
One of your XACML samples in the document shows an AttributeValue following an AttributeDescriptor in a Match expression.  Is that a hand-written example?  I seem to recall the 3.0 core spec requires the AttributeValue always appear before the AttributeDesignator/Selector.

-Danny

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


> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Jean-Paul Buu-Sao
> Sent: Thursday, June 28, 2012 12:54 AM
> To: Erik Rissanen; xacml@lists.oasis-open.org
> Subject: RE: [xacml] Proposed Agenda for 28 June TC Meeting
>
> Erik,
>
> On feedback 1,  then policy-id (identifier of a policy) will be clearer than
> policy-label (human-readable indication of a policy). So for example, such
> resource attribute designator would then be expressed as:
>
> <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-
> category:resource"
>    AttributeId="urn:oasis:names:tc:xacml:3.0:resource:policy-id"
>    MustBePresent="false"
>    DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>
>
> On feedback 2, what I am proposing is a single policy-template with multiple
> policy-template-parameters (your first interpretation) rather than a single
> policy with multiple conditions. Imagine that the number of possible
> instances (i.e. final, parameterized, policies) can be very large, which is
> exactly the case in the TAA example. It is far more workable to distribute to a
> large number of organizations one single TAA policy-template, and then
> distribute to a large number of organizations the few number of policy-
> template-parameters that would be needed (by the tools as you said) to
> locally construct the actual policies.
>
> I agree with you that there is no change required at run time. The proposal
> then is not to change anything to XACML 3.0, but to propose a profile for
> policy templates, that would define:
> a) How XACML 3.0 can be used to express policy templates
> b) How XACML 3.0 can be used to express policy templates parameters
> c) The workflow that tools would follow so policy templates and policy
> templates parameters can be combined to produce actual policy template
> instances
>
> Attached is a revised version of the feedback with examples, that hopefully
> help clarify the proposal.
>
> Policy template = example 3
> Policy template parameter 1 = example 4
> Policy template parameter 2 = example 5
>
> Tool would produce the actual policy template instance (example 1) by
> combining policy template (example 3) with policy template parameter
> (example 4)
>
> I hope that this makes sense. Now I heard someone saying, during the last
> meeting, that some of this parameterization could be achieved using existing
> constructs. Do you know what this referred to?
>
> Jean-Paul Buu-Sao
>
>
>
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Erik Rissanen
> Sent: Thursday, June 28, 2012 07:23
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Proposed Agenda for 28 June TC Meeting
>
> Jean-Paul,
>
> My comments are below.
>
> Regarding policy binding by reference, this can be easily achieved with the
> current functionality, like you explain yourself, but I don't think it is necessary
> to define a new attribute category. Defining a resource attribute would be
> enough. Something like:
>
> urn:oasis:names:tc:xacml:3.0:resource:policy-label
>
> The policy/PDP can then use this to select the applicable policy among many,
> just by the normal XACML mechanisms (or some optimized behavior in a
> particular environment if needed).
>
> Regarding parametrized policies, maybe I don't understand it correctly, but I
> can interpret it in two ways.
>
> The first is to see them as policy templates. In that case, I think it is a matter
> of tooling to fill in the templates in the system at the appropriate time, not
> that we need to modify the standard.
>
> My other interpretation is that you want the same policy to behave
> differently depending on some data in the request. In that case you should
> simply use a condition rather than a target, since then you can "fill in the
> template" by passing in attributes in the request. With a condition you can
> match two attributes against each other, not just one attribute against a
> constant value.
>
> Best regards,
> Erik
>
>
>
>
> On 2012-06-28 07:02, Jean-Paul Buu-Sao wrote:
> > Bill,
> >
> > Per the minutes I expected that we would also discuss the Feedback from
> TSCP on XACML 3.0 Public review 04? In particular it was mentioned that the
> parameterized policies, that TSCP is calling for could be partially achieved
> using e.g. VariableDefinition?
> >
> > Thanks,
> > Jean-Paul Buu-Sao
> >
> > -----Original Message-----
> > From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
> > On Behalf Of Bill Parducci
> > Sent: Thursday, June 28, 2012 03:07
> > To: XACML TC
> > Subject: [xacml] Proposed Agenda for 28 June TC Meeting
> >
> > Time: 13:00 EDT (GMT-0400)
> > Tel: 513-241-0892
> > Access Code: 65998
> >
> > Proposed Agenda for 28 June 20112 TC Meeting:
> >
> > I  Roll Call & Minutes
> >
> >    Approve Minutes:
> >     14 June 2012 TC Meeting
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00030.html
> >
> > II. Administrivia
> >
> >    XACML v3 Combining Algorithm uploaded
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00031.html
> >
> >    XACML TC Summary Overview
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00032.html
> >
> >    XACML Interop demo opportunities
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00034.html
> >
> >    Status XACML IPC v1.0 Profile
> >
> > III. Issues
> >
> >    Proposed PAP Architecture
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00026.html
> >     (continuation of thread)
> >
> >    JSON Mapping
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00024.html
> >
> >    Metadata Profile inquiry
> >     https://lists.oasis-open.org/archives/xacml/201206/msg00011.html
> >
> >    REST Profile API/PolicyId/General Plan
> >     (no recent postings)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: xacml-help@lists.oasis-open.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: xacml-help@lists.oasis-open.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org