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 "http://schemas.tscp.org/2012-03/claims/OrganizationID" must be in
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-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Curtiss</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Packard</AttributeValue>
</Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID" DataType="http://www.w3.org/2001/XMLSchema#string" />
</Apply>
(etc...)
</Condition>
Here is the excerpt of a policy (TAA-1.2), expressing that the subject attribute "http://schemas.tscp.org/2012-03/claims/OrganizationID" must be in
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-one-member-of">
<Apply functionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Curtiss</AttributeValue>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Spad</AttributeValue>
</Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID" DataType="http://www.w3.org/2001/XMLSchema#string" />
</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-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>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID" DataType="http://www.w3.org/2001/XMLSchema#string" />
</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-one-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"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</Apply>
<AttributeDesignator AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID" DataType="http://www.w3.org/2001/XMLSchema#string" />
</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 [https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile] be 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:]
Sent: Tuesday, October 09, 2012 08:32
To: Steven Legg
Cc: Jean-Paul Buu-Sao; Danny Thorpe;
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
>>>>> (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile%20Examples)?
>>>>> 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:*
>>>>> [mailto:] *On Behalf Of *Danny Thorpe
>>>>> *Sent:* Thursday, October 04, 2012 20:11
>>>>> *To:* Erik Rissanen;
>>>>> *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:*
>>>>> <mailto:>
>>>>> [mailto:]
>>>>> <mailto:[mailto:]> *On Behalf Of *Erik
>>>>> Rissanen
>>>>> *Sent:* Thursday, October 04, 2012 4:42 AM
>>>>> *To:*
>>>>> <mailto:>
>>>>> *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
>>>>> (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile)
>>>>> 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 <http://www.quest.com>
>>>>>
>>>>
>>>
>>
>
