For sake of clarity I would like to rephrase the thought
process.
<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">
</Apply>
</Apply>
(etc...)
</Condition>
<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">
</Apply>
</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">
</Apply>
</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">
</Apply>
</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.
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
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
>>>>> *Sent:* Thursday, October 04, 2012
20:11
>>>>> *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
>>>>> Rissanen
>>>>> *Sent:* Thursday, October 04, 2012
4:42 AM
>>>>> *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
>>>>> 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/ |
>>>>>
>>>>
>>>
>>
>