OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]