Jean-Paul,
The PDP would find the values through its context handler and PIP
configuration.
Also, if you really need to do a template, you can simply use the
attribute designator as your syntax. There is no need for any new
syntax. Any Policy Template Engine can simply be configured to
replace one or more of the attribute designators with static
values.
Best regards,
Erik
On 2012-10-09 10:40, Jean-Paul Buu-Sao wrote:
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>
>>>>>
>>>>
>>>
>>
>
