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] Updated policy template wiki


Jean-Paul,

Thanks, that was very helpful and clarified many things for me. :-)

Yes, you are right that if we would use policies with attribute designators, we are still missing the corresponding artifact to the "policy template data artifact". This needs to be defined. I think I said in some of my previous emails that you can pretty much use the policy template data artifact as you defined it, with maybe some small changes, to distribute the values for the PIP.

And yes, I believe the attribute designator approach can solve both of your use cases. This is simply because the attribute designator approach is almost identical to the template approach, except for naming. This is in fact why I don't like the template approach, since we already have the attribute designators. Of course, we need a format for the distribute the values to substitute. For that we could base it on the template data examples you provided, or perhaps use something existing, like SAML attribute assertions.

Best regards,
Erik

On 2012-10-10 13:39, Jean-Paul Buu-Sao wrote:
Erik,
 
Your question: "If you are targeting something else than XACML, then this should not affect the XACML spec, right?"
Erik: I was unclear. I am proposing a template profile regardless of the target execution mechanism, because I believe that this template makes XACML more capable. Now we should recognize than note everyone intents to using XACML as authorization engine. I used PLASMA as an illustration. If we want them to considering XACML as a front-end language, then we certainly want the good capabilities that we introduce to be available to them as well. Said differently, if the the flexibility of templates must be provided at the front-end of the language, then use-case 1a is much required.
 
Your question: "I don't understand why <Parameter> is seen as simpler than <AttributeDesignator>. They are virtually identical."
Erik, the question is: how does the binding occurs between the policy-template and an associated policy-template data?
 
Policy-Template: binds to policy-template data via the ParameterId attribute (here: "organizations")
 
<Policy xmlns:pt="urn:policy-template-namespace" pt:type="template" pt:version="1.0" PolicyId="urn:us:ddtc:itar:taa" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
   (...)
    <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
      <Apply xsi:type="AtLeastMemberOf" functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
        <Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
          <AttributeValue ParameterId="organizations" DataType=http://www.w3.org/2001/XMLSchema#string/>
        </Apply>
      </Apply>
    (...)
    </Condition>
   (...)
</Policy>
 
Policy-template data: : binds to policy-template via the TemplateId attribute (here: "urn:us:ddtc:itar:taa")
 
<Policy xmlns:pt="urn:policy-template-namespace" pt:type="data" pt:TemplateId="urn:us:ddtc:itar:taa" PolicyId="urn:curtiss:ba:taa:taa-1.1"  >
  <Description>Policy instance TAA-1.1, that refers to ITAR-TAA policy-template</Description>
  <Parameters>
    <Parameter ParameterId="organizations">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Curtiss</AttributeValue>
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Packard</AttributeValue>
    </Parameter>
  </Parameters>
</Policy>
 
What would be these artifacts, and their mutual bindings, become in the case you use <AttributeDesignator>?
 
In your proposal I see that you are down to one artifact only, the policy-template, that would become:
 
<Policy xmlns:pt="urn:policy-template-namespace" pt:type="template" pt:version="1.0" PolicyId="urn:us:ddtc:itar:taa" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
   (...)
    <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
      <Apply xsi:type="AtLeastMemberOf" functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-one-member-of">
        <Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
           <AttributeDesignator MustBePresent="true" AttributeId="Organizations" DataType="http://www.w3.org/2001/XMLSchema#string"/>
        </Apply>
      </Apply>
    (...)
    </Condition>
   (...)
</Policy>
 
But in absence of a policy-template data artifact, how can you distribute the values to be substituted (i.e. the string-bag {“Curtiss”, ‘Packard”})? I understand that, in your view, these parameters are part of the “PIP dataset”. But how can the concept of “parameter(template-name=”urn:us:ddtc:itar:taa”, parameter-name=”Organizations”, parameter-value={”Curtiss”, “packard”}) be distributed and deployed to your PIP dataset?
 
Your question: “Which use case is this? In the email below 1a is just a statement saying there are lots of policies. I don't see a use case.”
 
Erik, sorry for the confusion, I meant “use-case 1”, and was referring to the first use-case of the 2 use-cases indicated on the Wiki. For completeness, here are the two use-case again:
  1. Intra-organization use case: allows policy authoring tools to create an enterprise policy structure which would be used by multiple security officers to create business specific policy instances. The policy template reduction process occurs within the policy authority
  • A policy template that has been proofed once, with respect to the access rules, can be reused over and over with different set of data, drastically reducing risk for errors
  1. In the context of secure collaboration across organizations, allows a policy authority to distribute a policy template to all contributing organizations, and template data to individual organizations that allow generating business context specific policy instances. The policy template reduction process occurs outside of the policy authority
  • Export control: the US DDTC policy authority can distribute policy templates for ITAR to organizations, letting organizations provide the parameter data that thy use to generate the business specific TAA
 
Regards,
Jean-Paul
 
 
-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Wednesday, October 10, 2012 12:14
To: Jean-Paul Buu-Sao
Cc: Steven Legg; Danny Thorpe; xacml@lists.oasis-open.org; Hal Lockhart (hal.lockhart@oracle.com)
Subject: Re: [xacml] Updated policy template wiki
 
Jean-Paul,
 
See inline.
 
On 2012-10-10 12:02, Jean-Paul Buu-Sao wrote:
> Erik,
>
> 1a is needed in the following two cases (there may be others):
>
> 1) The policy authority wants to use XACML 3.0 as a pivotal language for the conveyance of access rules across administrative domains, without imposing a XACML runtime on each implementing organization. For example, we (at TSCP) are currently trying to convince IETF PLASMA that XACML should be a pivotal language for the _expression_ of access rules, even though execution mechanism will not be based upon a XACML engine.
 
If you are targeting something else than XACML, then this should not affect the XACML spec, right?
 
> 2) The policy authority wants to using a templating mechanism "just" for the sake of simplifying the authoring of a large number of policy instances. This requires templating to be useable in policy authoring tools alone, well before any execution mechanism (PDP, PIP) comes to play. I think that Hal has this use-case in mind as well (Hal to confirm).
 
I don't understand why <Parameter> is seen as simpler than <AttributeDesignator>. They are virtually identical.
 
> Conceptually there are two distinct artifacts, that are both identifiable, and both subject to individual (separate) distribution.
> a) The policy template. Example: the generic TAA (Technical Assistance Agreement) template, which identifier is, say "urn:us:ddtc:itar:taa"
 
This could instead be an XACML policy with attribute designators instead of parameters in a template.
 
> b) A policy-template data. Example: the policy-template data TAA-1.1 contains the parameters required to instantiate a TAA for a business context. Its identifier is, say "urn:curtiss:ba:taa:taa-1.1"
 
This could instead be a dataset which is distributed to be used in a PIP. In fact, you could probably use the very file format from your examples as the backend datastore for a PIP.
 
> Ownership and lifecycle of a policy-template and of all its potential policy-template data artifacts must be kept distinct. Coming back to the example above, we need to have two artifacts, "TAA.xacml" and "TAA-Data-1.1.xacml", that can evolve independently of each other. The only condition really is that the policy-template data "TAA-Data-1.1.xacml" contains a reference to the template (identified as "urn:us:ddtc:itar:taa"). This allows anyone to update, whenever required, either artifacts.
 
Yes, and you can update the policy with attribute designator and the PIP dataset independently of each other as well.
 
 
> In your suggestion of the PIP playing a role on the fetching of the correct parameters, how does the PIP know where to take the parameters from (how is this indicated to him)? Is this by configuration?
 
The organization using the policy would deploy the PIP data set (which
is the same information as in your template value data set) in their PIP.
 
>   We need to understand the proposed, end-to-end mechanism, so to verify that the conceptual characteristics are preserved. Also, I have asked you this question before: would you confirm that your proposed mechanism does not support the static use-case 1a?
 
Which use case is this? In the email below 1a is just a statement saying
there are lots of policies. I don't see a use case.
 
Best regards,
Erik
 
>
> Thanks,
> Jean-Paul
>
>
> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Wednesday, October 10, 2012 11:17
> To: Jean-Paul Buu-Sao
> Cc: Steven Legg; Danny Thorpe; xacml@lists.oasis-open.org
> Subject: Re: [xacml] Updated policy template wiki
>
> Jean-Paul,
>
> Ok, thanks that clarifies where we are in disagreement.
>
> I don't understand why you need 1a) and 1b).
>
> Instead, you could distribute an XACML policy which has attribute designators instead of parameters. Then, in an alternative step 2, the organization has a PDP which has a PIP which provides the n policy data in the form of attributes during policy evaluation.
>
> Why does this not work for you?
>
> Best regards,
> Erik
>
>
> On 2012-10-10 09:45, Jean-Paul Buu-Sao wrote:
>> Erik,
>>
>> Trying via a different angle. Let us first concentrate on the requirement, ignoring the modality (static, dynamic), exact mechanism (PIP involves or not)  and syntax.
>>
>> 1a) I have a very large number of policies (say, N > 10000) that are all identical, except for the constant values that contain in their access rules. Every single one of these policies has a unique identity.
>> 1b) We build one template which, given the correct dataset, can
>> produce the same N policy instances
>>
>> Let now introduce the modality. There are two use-cases:
>>
>> 2a) The policy authority uses the template mechanism to ease the
>> production of the N policy instances, which are all produced before
>> being distributed for execution. Organizations implementing the policy
>> do not see the policy template, only the N policy instances
>> 2b) The policy authority distributes the its policy template to
>> organizations. Each organization need to supply n policy data (n is a
>> small number, typically between 1 and 100) which, combined with the
>> policy template, produces n policy instances
>>
>> The "iteration" can occur on either 2a or 2b (i.e. iterate through N policy data, or through n policy data). Objective is to produce the N or n policy instances.
>> The produces policy instances are (my original proposal), just plain core XACML 3.0 policies, that then can be used to provide standard authorization decision.
>>
>> The discussion became confusing with the introduction of possible dynamic reduction, occurring at the time of authorization decision. Then the reduction mechanism needs to know the policy template and the policy dataset so it can reduce the policy instance, before evaluating the rules with input from (subject, resource, environment) attributes.
>>
>> Again I want to stress out that whatever mechanism and syntax need to support both use cases 1a and 1b.
>>
>> I hope this helped
>> Jean-Paul
>>
>> -----Original Message-----
>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>> Sent: Wednesday, October 10, 2012 09:25
>> To: Steven Legg
>> Cc: Danny Thorpe; Jean-Paul Buu-Sao; xacml@lists.oasis-open.org
>> Subject: Re: [xacml] Updated policy template wiki
>>
>> Steven,
>>
>> Sorry, but it's still a bit unclear to me. Ok, I get it that if you have one template and N template datasets, then you get N policies.
>>
>> But why does that matter?
>>
>> When a PEP calls to a PDP, the PDP is supposed to provide a single decision (not doing multi requests now) so this iteration does not need to happen. The PIP only needs to select the one dataset which applies to this particular request.
>>
>> Best regards,
>> Erik
>>
>>
>>
>> On 2012-10-10 08:58, Steven Legg wrote:
>>> Erik,
>>>
>>> On 10/10/2012 4:57 PM, Erik Rissanen wrote:
>>>> Steven,
>>>>
>>>> Whatever information you are using to select the right template data
>>>> when filling in the right template with the right data, could also
>>>> be available to a PIP which would then know which attribute values
>>>> to provide for any attribute designator. Or is there something I
>>>> don't understand in the discussion?
>>> The singular/plural ambiguity around "data" in policy template data
>>> is bothersome, and not helpful to clarity, so I'm going to start
>>> saying policy template data set (singular) and policy template data
>>> sets (plural).
>>>
>>> In the case of a Policy Template Engine (PTE), the inputs are a
>>> policy template and any number of policy template data sets. The PTE
>>> just goes into a loop where it makes a copy of the policy template
>>> replacing the parameters in the template (in whatever syntax is used
>>> to represent them) with the corresponding parameter values in the
>>> current policy template data set it is considering in the current
>>> iteration of the loop. The PTE considers one, and only one, policy
>>> template data set in each iteration. The values of the parameters,
>>> either single values or bags, will typically be different on each
>>> iteration because they come from a different policy template data set.
>>> Each time around the loop the PTE spits out a policy template
>>> instance, which is a normal policy without parameters. If there are N
>>> policy template data sets, then there are N output policies. There is
>>> no explicit information that the PTE uses to decide which policy
>>> template data set to use.
>>> The selection is inherent in the loop it performs.
>>>
>>> Dynamic template reduction has to have the same effect as a PTE,
>>> which means that the PDP has to evaluate the policy template, which
>>> is now masquerading as a normal policy, as many times as there are
>>> policy template data sets known to the PIP (or alternatively, the
>>> context handler). Effectively, PIPs currently act as though there is
>>> only ever one policy template data set.
>>> Standard PIPs don't
>>> have the capability of storing multiple alternative sets of
>>> attributes. Nor is there a mechanism that a PDP could use to tell the
>>> PIP which set it wants right now.
>>>
>>> Any clearer ?
>>>
>>> Regards,
>>> Steven
>>>
>>>> Best regards,
>>>> Erik
>>>>
>>>> On 2012-10-10 03:28, Steven Legg wrote:
>>>>> Danny,
>>>>>
>>>>> On 10/10/2012 4:59 AM, Danny Thorpe wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> The equivalent of dynamic policy template reduction would require
>>>>>> setting up a PIP with the PDP to provide the appropriate
>>>>>> template-data values for a particular attribute ID when the PDP
>>>>>> evaluates the <AttributeDesignator>.  The PIP would need to be
>>>>>> able to distinguish between your two template cases below
>>>>>> (Curtiss, Packard vs Curtiss, Spad). If the PIP knew the context
>>>>>> of which policy ID an <AttributeDesignator> was being evaluated
>>>>>> in, the PIP could make the decision of whether to return (Curtiss,
>>>>>> Packard) or (Curtiss,
>>>>>> Spad) to provide the semantics of the original policy template
>>>>>> concept.  Knowledge of the PDP evaluation state by PIPs is not
>>>>>> part of the XACML spec, but could be provided by an implementation.
>>>>>>
>>>>>> I could imagine manipulating the policy ID to indicate what
>>>>>> substitution group(s) the policy belongs to.
>>>>>> Policy template (ID = "ABC") + parameter data set 1 => policy
>>>>>> ID="ABC/1". Policy template (ID = "ABC") + parameter data set 2 =>
>>>>>> policy ID="ABC/2".  The policy bodies are identical, but their IDs
>>>>>> differ.
>>>>>>
>>>>>> A more generalized solution would be to tie the parameter
>>>>>> substitution group selection to some artifact of the request
>>>>>> (subject, resource) or the environment (PDP host organization).
>>>>>> PIP returns parameter data set 1 for the target attribute ID if
>>>>>> the request context also contains a "green apple" attribute, else
>>>>>> the PIP returns parameter data set 2.  PIP returns parameter data
>>>>>> set 1 if the organization's country is X, parameter data set 2 if
>>>>>> the organization's country is Y, etc.
>>>>>>
>>>>>> But the PIP only needs to be that smart if the PDP is multi-tenant.
>>>>>> In the use case of a shared policy
>>>>>> (template) needing to be customized to a particular organization's
>>>>>> specific details (parameter data), if the PDP is dedicated to that
>>>>>> one organization, the PIP could simply be loading the specific
>>>>>> details (parameter
>>>>>> data) from a config file. No need for decision branches in the PIP
>>>>>> at all.
>>>>> You only seem to be considering one possibility of use case 2 of
>>>>> the Policy Template Profile. I read use case 2 as allowing that the
>>>>> customization for a particular organization (i.e., the organization
>>>>> making use of the policy template, not the organizations that might
>>>>> be mentioned in the parameter
>>>>> data) could involve many policy template data. Those policy
>>>>> template data may overlap with the policy template data of another
>>>>> organization using the same template, or be completely different
>>>>> from the policy template data used by another organization using
>>>>> the same template. Use case 1 also calls for many policy template
>>>>> data in use at the same organization. I seem to recall it being
>>>>> written somewhere that the policy template data may number in the thousands.
>>>>>
>>>>> For dynamic template reduction where there are multiple policy
>>>>> template data, we can't rely on information in the request to cause
>>>>> the PIP to select one parameter group. The PDP has to repeatedly
>>>>> evaluate the policy template causing (somehow) the PIP to return a
>>>>> different parameter group each time, each parameter group
>>>>> corresponding to a different policy template data, and this must
>>>>> occur during the evaluation of a single authorization request.
>>>>>
>>>>> Regards,
>>>>> Steven
>>>>>
>>>>>> -Danny
>>>>>>
>>>>>> *Danny Thorpe *
>>>>>>
>>>>>> Authorization Architect
>>>>>>
>>>>>> *Dell*| Identity & Access Management, Quest Software
>>>>>>
>>>>>> Quest Software is now part of Dell.
>>>>>>
>>>>>> *From:*Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
>>>>>> *Sent:* Tuesday, October 09, 2012 1:40 AM
>>>>>> *To:* Erik Rissanen; Steven Legg
>>>>>> *Cc:* Danny Thorpe; xacml@lists.oasis-open.org
>>>>>> *Subject:* RE: [xacml] Updated policy template wiki
>>>>>>
>>>>>> For sake of clarity I would like to rephrase the thought process.
>>>>>>
>>>>>> Here is the excerpt of a policy (TAA-1.1), expressing that the
>>>>>> subject attribute
>>>>>> the bag {"Curtiss", "Packard"}
>>>>>>
>>>>>>        <Condition
>>>>>> FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
>>>>>>
>>>>>>          <Apply xsi:type="AtLeastMemberOf"
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-
>>>>>> o
>>>>>> ne-member-of">
>>>>>>
>>>>>>
>>>>>>            <Apply
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>>>>>>
>>>>>> <AttributeValue
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string">Curtiss</Attrib
>>>>>> u
>>>>>> teValue>
>>>>>>
>>>>>>              <AttributeValue
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string">Packard</Attrib
>>>>>> u
>>>>>> teValue>
>>>>>>
>>>>>>            </Apply>
>>>>>>
>>>>>>            <AttributeDesignator
>>>>>>
>>>>>>          </Apply>
>>>>>>
>>>>>>          (etc...)
>>>>>>
>>>>>>        </Condition>
>>>>>>
>>>>>> Here is the excerpt of a policy (TAA-1.2), expressing that the
>>>>>> subject attribute
>>>>>> the bag {"Curtiss", "Spad"}
>>>>>>
>>>>>>        <Condition
>>>>>> FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
>>>>>>
>>>>>>          <Apply xsi:type="AtLeastMemberOf"
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-
>>>>>> o
>>>>>> ne-member-of">
>>>>>>
>>>>>>
>>>>>>            <Apply
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>>>>>>
>>>>>> <AttributeValue
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string">Curtiss</Attrib
>>>>>> u
>>>>>> teValue>
>>>>>>
>>>>>>              <AttributeValue
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string">Spad</Attribute
>>>>>> V
>>>>>> alue>
>>>>>>
>>>>>>            </Apply>
>>>>>>
>>>>>>            <AttributeDesignator
>>>>>>
>>>>>>          </Apply>
>>>>>>
>>>>>>          (etc...)
>>>>>>
>>>>>>        </Condition>
>>>>>>
>>>>>> The two policies (TAA-1.1 and TAA-1.2) are similar, with the
>>>>>> exception of the hard-coded values of the string bags used by the
>>>>>> AtLeastMemberOf function. The idea is to have only one policy that
>>>>>> does not contain these hard-coded values. Instead we have a
>>>>>> construct that would substitute the appropriate values. In the
>>>>>> example above: {"Curtiss", "Packard"} for TAA-1.1, {"Curtiss",
>>>>>> "Spad"} for TAA-1.2.
>>>>>>
>>>>>> My initial proposal was to using the element <AttributeValue>
>>>>>> without qualifying its contents values, but by specifying a
>>>>>> ParameterId attribute, that would allow to substitute the
>>>>>> appropriate values:
>>>>>>
>>>>>>        <Condition
>>>>>> FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
>>>>>>
>>>>>>          <Apply xsi:type="AtLeastMemberOf"
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-
>>>>>> o
>>>>>> ne-member-of">
>>>>>>
>>>>>>
>>>>>>            <Apply
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>>>>>>
>>>>>> <AttributeValue ParameterId="organizations"
>>>>>>
>>>>>>            </Apply>
>>>>>>
>>>>>>            <AttributeDesignator
>>>>>>
>>>>>>          </Apply>
>>>>>>
>>>>>>        (etc...)
>>>>>>
>>>>>>        </Condition>
>>>>>>
>>>>>> I understand that instead, and in order to achieving the same
>>>>>> effect, Erik's proposal is to replace the <AttributeValue
>>>>>> ParameterId=...> construct with the more standard
>>>>>> <AttributeDesignator> construct, given something like:
>>>>>>
>>>>>>        <Condition
>>>>>> FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">
>>>>>>
>>>>>>          <Apply xsi:type="AtLeastMemberOf"
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-at-least-
>>>>>> o
>>>>>> ne-member-of">
>>>>>>
>>>>>>
>>>>>>            <Apply
>>>>>> functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>>>>>>
>>>>>> <AttributeDesignator
>>>>>> CategoryId="urn:oasis:names:tc:xacml:1.0:policy:"
>>>>>> AttributeId="organizations"
>>>>>>
>>>>>>            </Apply>
>>>>>>
>>>>>>            <AttributeDesignator
>>>>>>
>>>>>>          </Apply>
>>>>>>
>>>>>>        (etc...)
>>>>>>
>>>>>>        </Condition>
>>>>>>
>>>>>> If my interpretation is correct (at least on the intent, not on
>>>>>> exact syntax; Erik, I apologize if I totally missed your point),
>>>>>> then some questions arise:
>>>>>>
>>>>>> A.1) How would the authorization engine know where to go and fetch
>>>>>> the desired values (i.e. from the TAA-1.1 template-data or the
>>>>>> TAA-1.2 template-data)?
>>>>>>
>>>>>> A.2) The <AttributeDesignator> construct was, so far, meant to
>>>>>> retrieve attributes values from (Subject, Resource, Environment)
>>>>>> attributes. Are we introducing the possibility for the same
>>>>>> construct to also retrieve attribute values from (policy-template)
>>>>>> attributes? If so we need to make it explicit on the
>>>>>> specification, I would think.
>>>>>>
>>>>>> B) Can the two use-cases called out at the beginning of
>>>>>> supported by <AttributeDesignator>?
>>>>>>
>>>>>> I assumed that use-case 1 requires a static reduction, that
>>>>>> happens far before any actual authorization decision; hence
>>>>>> <AttributeDesignator> cannot be used for the purpose of
>>>>>> parameterization. If my assumption is correct, then we need a
>>>>>> different mechanism to support use-case 1, which is damageable. My
>>>>>> proposal was to find a single syntax that would equally support
>>>>>> both use-cases.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jean-Paul
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Erik Rissanen [mailto:erik@axiomatics.com]
>>>>>> Sent: Tuesday, October 09, 2012 08:32
>>>>>> To: Steven Legg
>>>>>> Cc: Jean-Paul Buu-Sao; Danny Thorpe; xacml@lists.oasis-open.org
>>>>>> Subject: Re: [xacml] Updated policy template wiki
>>>>>>
>>>>>> Steven,
>>>>>>
>>>>>> I am arguing against the whole concept of a template, thus there
>>>>>> is no Policy Template Engine in my proposal.
>>>>>>
>>>>>> What I am trying to say is that instead of adding a Policy
>>>>>> Template Engine to the PDP before the policy is evaluated by the
>>>>>> XACML engine, you can just use a regular XACML policy in the XACML
>>>>>> engine.
>>>>>>
>>>>>> You can solve the same use case this way. Say that you want a
>>>>>> template which has a parameter called "foo"
>>>>>> and then a Policy Template Engine which substitutes "foo" with
>>>>>> values before the XACML engine. Instead you can have a regular
>>>>>> XACML policy with attribute designator "foo" and a PIP which
>>>>>> provides the value which would have been provided by the policy
>>>>>> template engine.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> On 2012-10-09 02:46, Steven Legg wrote:
>>>>>>
>>>>>>> Erik,
>>>>>>> Sorry, I read too much into what you were saying. Please
>>>>>>> disregard my previous response.
>>>>>>> On 8/10/2012 5:38 PM, Erik Rissanen wrote:
>>>>>>>> Steven,
>>>>>>>> Yes, just replace all parameters with attribute designators.
>>>>>>> An issue with using attribute designators as parameters is that
>>>>>>> there is ambiguity for the Policy Template Engine to resolve.
>>>>>>> Some attribute designators in the policy template are "real" and
>>>>>>> are preserved as is, and the other attribute designators are
>>>>>>> actually parameters that need to be replaced by a bag of
>>>>>>> attribute values from the policy template data.
>>>>>>> Your example only has one parameter as a designator and that
>>>>>>> designator uses the same URI for the Category and AttributeId.
>>>>>>> Were
>>>>>>> you intending that equivalence as a way of distinguishing an
>>>>>>> attribute designator that is actually a parameter, or is it just
>>>>>>> because you had to put something in the Category ? A Policy
>>>>>>> Template Engine could always look in the policy template data to
>>>>>>> work out which designators are really parameters, but I think it
>>>>>>> would be better if it were clear from the designator. I suggest
>>>>>>> using a special category URI just for parameters.
>>>>>>> The attribute designators that are actually parameters should
>>>>>>> always use MustBePresent="true" so that an implementation that
>>>>>>> blindly evaluates a policy template as a normal policy will
>>>>>>> appropriately return an indeterminate decision.
>>>>>>> It seems we have three proposals for representating parameters in
>>>>>>> policy
>>>>>>> templates:
>>>>>>> (1) Just use attribute designators. This means that targets can't
>>>>>>> have parameters, but on-permit-apply-second can be used to get
>>>>>>> the same effect.
>>>>>>> Policy template data writers can determine whether a parameter is
>>>>>>> single-valued or multi-valued by seeing whether the corresponding
>>>>>>> attribute designator is wrapped in type-one-and-only.
>>>>>>> (2) <ValueParameter> and <BagParameter> elements. Targets can
>>>>>>> have value parameters, but not bag parameters, though
>>>>>>> on-permit-apply-second can be used to get the same effect. It's
>>>>>>> obvious to policy template data writers what the parameters are
>>>>>>> and whether a parameter is single-valued or multi-valued.
>>>>>>> (3) ParameterId XML attribute on <AttributeValue> elements. It's
>>>>>>> reasonably obvious to policy template data writers what the
>>>>>>> parameters are. An additional XML attribute to indicate whether
>>>>>>> the parameter is single-valued or multi-valued would make this
>>>>>>> solution cleaner.
>>>>>>> Targets can have value parameters. Targets could also have bag
>>>>>>> parameters provided the target is transformed by the Policy
>>>>>>> Template Engine. Alternatively, bag parameters in targets could
>>>>>>> be disallowed because on-permit-apply-second can be used to get
>>>>>>> the same effect.
>>>>>>> I don't see a compelling need for transformations of conditions.
>>>>>>> Proposals
>>>>>>> (1) and (2) don't lend themselves to transformations, but it
>>>>>>> could be done.
>>>>>>> The difference in the proposals is mostly around the syntax for
>>>>>>> representing parameters.
>>>>>>> Regards,
>>>>>>> Steven
>>>>>>>> I don't understand why you need to evaluate the template twice.
>>>>>>>> I tried to understand it from the wiki, but to me it all looks
>>>>>>>> like simple value substitution, which can handled better with
>>>>>>>> attribute designators.
>>>>>>>> Best regards,
>>>>>>>> Erik
>>>>>>>> On 2012-10-08 04:32, Steven Legg wrote:
>>>>>>>>> Erik,
>>>>>>>>> On 5/10/2012 6:03 PM, Erik Rissanen wrote:
>>>>>>>>>> Jean-Paul,
>>>>>>>>>> I put in one such example on the wiki page. Search for
>>>>>>>>>> "on-permit-apply-second" and you will find it.
>>>>>>>>> This strategy only works if there is one policy template data
>>>>>>>>> for the policy template. In general, there may be many policy
>>>>>>>>> template data per policy template. The example in the wiki has
>>>>>>>>> two:
>>>>>>>>> TAA-1.1 and TAA-1.2.
>>>>>>>>> Although you didn't do it, I assume you meant to replace the
>>>>>>>>> parameters in the condition with attribute designators as well,
>>>>>>>>> i.e., designators for "organizations", "nationals" and
>>>>>>>>> "workEfforts".
>>>>>>>>> The policy needs to be evaluated twice. The first time the
>>>>>>>>> attribute designator for PolicyIdOnResource needs to return
>>>>>>>>> "urn:curtiss:ba:taa:taa-1.1", the designator for "organizations"
>>>>>>>>> needs to return the bag of { "Curtiss", "Packard" }, the
>>>>>>>>> designator for "nationals" needs to return the bag of { "US",
>>>>>>>>> "GB" }, and "workEfforts" needs to return { "DetailedDesign",
>>>>>>>>> "Simulation" }.
>>>>>>>>> The second time, PolicyIdOnResource needs to return
>>>>>>>>> "urn:curtiss:ba:taa:taa-1.2", "organizations" needs to return {
>>>>>>>>> "Curtiss", "Spad" }, "nationals" needs to return { "US", "FR" }
>>>>>>>>> and "workEfforts"
>>>>>>>>> needs to return { "Integration", "Simulation" }.
>>>>>>>>> Of course, we don't currently have a way to cause a policy to
>>>>>>>>> be evaluated multiple times with the attribute designators
>>>>>>>>> returning different bags each time. For one thing, the result
>>>>>>>>> of an attribute designator is fixed for the entire duration of
>>>>>>>>> the processing of an authorization request. The expansion of
>>>>>>>>> the policy template into a policy template instance for each
>>>>>>>>> policy template data achieves the same end.
>>>>>>>>> The use of on-permit-apply-second is a good idea for removing
>>>>>>>>> the need for any special processing of parameters in targets.
>>>>>>>>> Regards,
>>>>>>>>> Steven
>>>>>>>>>> Best regards,
>>>>>>>>>> Erik
>>>>>>>>>> On 2012-10-04 23:01, Jean-Paul Buu-Sao wrote:
>>>>>>>>>>> Greetings,
>>>>>>>>>>> Apologies for missing the call today, as I was in a TSCP
>>>>>>>>>>> event, together with Gerry and David of Axiomatics.
>>>>>>>>>>> I have been much interested in the last findings, and agree
>>>>>>>>>>> that if the "template" property that we are (all, I think)
>>>>>>>>>>> looking for could be achieved with standard the
>>>>>>>>>>> <AttributeDesignator> construct, rather than introducing new
>>>>>>>>>>> concepts, then this would be for the better.
>>>>>>>>>>> May I suggest that, in order to verify this assertion (so to
>>>>>>>>>>> speak), some folks, such as Erik or Danny, would be kind
>>>>>>>>>>> enough to propose an alternate proposal to the sample found
>>>>>>>>>>> on our Wiki
>>>>>>>>>>>
>>>>>>>>>>> By the way, as a word of
>>>>>>>>>>> caution, please disregard the in-correctness of the XCAML 3.0
>>>>>>>>>>> of section 1. of the example (yes the devil is in the
>>>>>>>>>>> details, and David shown me how this example could be made
>>>>>>>>>>> compliant).
>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>> Jean-Paul
>>>>>>>>>>> *From:*xacml@lists.oasis-open.org
>>>>>>>>>>> <mailto:[mailto:xacml@lists.oasis-open.org]> *On Behalf Of
>>>>>>>>>>> *Danny Thorpe
>>>>>>>>>>> *Sent:* Thursday, October 04, 2012 20:11
>>>>>>>>>>> *To:* Erik Rissanen; xacml@lists.oasis-open.org
>>>>>>>>>>> *Subject:* RE: [xacml] Updated policy template wiki When the
>>>>>>>>>>> original proposal for policy templates was brought forward, I
>>>>>>>>>>> noted that simply replacing a single AttributeValue element
>>>>>>>>>>> with a list of values from the policy template <Parameter>
>>>>>>>>>>> would fail in <Match> expressions, since <Match> is very
>>>>>>>>>>> explicit about one value, one designator/selector.  I offered
>>>>>>>>>>> a transform to help produce valid match expressions.
>>>>>>>>>>> AttributeDesignator does provide similar
>>>>>>>>>>> "insert-multiple-values-here" operations to the policy
>>>>>>>>>>> template substitution behavior, but I believe the suggestion
>>>>>>>>>>> of policy parameterization came up because of situations in
>>>>>>>>>>> which AttributeDesignator cannot be used. Comparing an
>>>>>>>>>>> attribute against a static list of test values (specific to
>>>>>>>>>>> an organization or location and applied to a generic policy),
>>>>>>>>>>> for example, is a many-to-many comparison, but cannot be
>>>>>>>>>>> expressed in a <Match> element.
>>>>>>>>>>> As we discussed on the TC call today, we're finding more
>>>>>>>>>>> difficulties with parameter substitution the deeper we dig.
>>>>>>>>>>> Steven
>>>>>>>>>>> Legg noted in an earlier email that some Xacml functions that
>>>>>>>>>>> take single <AttributeValue> won't work if multiple values
>>>>>>>>>>> are dropped in to replace the <AttributeValue>. This means
>>>>>>>>>>> some sort of _expression_ transform will be necessary in
>>>>>>>>>>> condition expressions as well to move policy templates
>>>>>>>>>>> forward.
>>>>>>>>>>> In light of these increasing complexities and challenges, I'm
>>>>>>>>>>> beginning to agree with you that perhaps the policy template
>>>>>>>>>>> use case can better be addressed using the existing
>>>>>>>>>>> <AttributeDesignator>.
>>>>>>>>>>> This would mean:
>>>>>>>>>>> 1.Giving up parameterization behavior in <Match> expressions
>>>>>>>>>>> and moving that logic into conditions using
>>>>>>>>>>> <AttributeDesignator> to reference an attribute ID
>>>>>>>>>>> representing the parameterization data.
>>>>>>>>>>> 2.Moving parameterization data from a static policy generator
>>>>>>>>>>> step to a PIP to fill <AttributeDesignator> references to a
>>>>>>>>>>> particular attribute ID with parameterization data in the PDP
>>>>>>>>>>> at auth request evaluation time.
>>>>>>>>>>> Using <AttributeDesignator> instead of policy templates does
>>>>>>>>>>> impact the use case quite a bit because populating PIP data
>>>>>>>>>>> is not part of the Xacml spec. Policies could be shared
>>>>>>>>>>> between organizations per the use case, but how the
>>>>>>>>>>> parameterization data is applied to those policies would
>>>>>>>>>>> become a vendor-specific implementation detail.
>>>>>>>>>>> I can see the attraction of parameterizing policies to allow
>>>>>>>>>>> up-front synthesis of specific policies, but as we say "the
>>>>>>>>>>> devil is in the details." The details are winning. :/ -Danny
>>>>>>>>>>> *Danny Thorpe * Authorization Architect Dell | Identity &
>>>>>>>>>>> Access Management, Quest Software Quest Software is not part
>>>>>>>>>>> of Dell.
>>>>>>>>>>> *From:*xacml@lists.oasis-open.org
>>>>>>>>>>> <mailto:[mailto:xacml@lists.oasis-open.org]> *On Behalf Of
>>>>>>>>>>> *Erik Rissanen
>>>>>>>>>>> *Sent:* Thursday, October 04, 2012 4:42 AM
>>>>>>>>>>> *To:* xacml@lists.oasis-open.org
>>>>>>>>>>> *Subject:* Re: [xacml] Updated policy template wiki All, I
>>>>>>>>>>> still fail to see why this is useful.
>>>>>>>>>>> If you take a policy template, and replace each <Parameter>
>>>>>>>>>>> with an appropriate <AttributeDesignator>, then you get a
>>>>>>>>>>> regular XACML policy, and the PEP/PDP can "fill in"
>>>>>>>>>>> the "template" at runtime using normal XACML attributes.
>>>>>>>>>>> Why do we need a new standard? In particular I would be
>>>>>>>>>>> opposed to "implementation option C", that is a PDP would
>>>>>>>>>>> construct the policy from the template at runtime.
>>>>>>>>>>> That's lots of heavy machinery for no gain.
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Erik
>>>>>>>>>>> On 2012-09-20 20:25, Danny Thorpe wrote:
>>>>>>>>>>>       I've updated the policy template wiki
>>>>>>>>>>> e
>>>>>>>>>>> )
>>>>>>>>>>>       with text about required Match _expression_ rewriting in
>>>>>>>>>>> parameter substitution and optional use of
>>>>>>>>>>>       AttributeDesignators and AttributeSelectors in Parameter
>>>>>>>>>>> data in dynamic policy template reduction
>>>>>>>>>>>       implementations.
>>>>>>>>>>>       -Danny
>>>>>>>>>>>       *Danny Thorpe *
>>>>>>>>>>>       Product Architect | | *Quest Software*- /Now including
>>>>>>>>>>> the people and products of BiTKOO/ | www.quest.com
 
 



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