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>
<AttributeDesignator
AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</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>
<AttributeDesignator
AttributeId="http://schemas.tscp.org/2012-03/claims/OrganizationID"
DataType="http://www.w3.org/2001/XMLSchema#string" />
</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:
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
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:]
Sent: Wednesday, October 10, 2012 12:14
To: Jean-Paul Buu-Sao
Cc: Steven Legg; Danny Thorpe; ; Hal
Lockhart ()
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:]
> Sent: Wednesday, October 10, 2012 11:17
> To: Jean-Paul Buu-Sao
> Cc: Steven Legg; Danny Thorpe;
> 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:]
>> Sent: Wednesday, October 10, 2012 09:25
>> To: Steven Legg
>> Cc: Danny Thorpe; Jean-Paul Buu-Sao;
>> 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:]
>>>>>> *Sent:* Tuesday, October 09, 2012
1:40 AM
>>>>>> *To:* Erik Rissanen; Steven Legg
>>>>>> *Cc:* Danny Thorpe;
>>>>>> *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
>>>>>> "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-
>>>>>> 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
>>>>>> 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-
>>>>>> 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
>>>>>> 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-
>>>>>> o
>>>>>> ne-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-
>>>>>> 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"
>>>>>> 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;
>>>>>> <mailto:>
>>>>>> 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:]
>>>>>>>>>>> <mailto:[mailto:]>
*On Behalf Of
>>>>>>>>>>> *Danny Thorpe
>>>>>>>>>>> *Sent:*
Thursday, October 04, 2012 20:11
>>>>>>>>>>> *To:* Erik
Rissanen;
>>>>>>>>>>> <mailto:>
>>>>>>>>>>> *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:]>
>>>>>>>>>>> <mailto:[mailto:]>
*On Behalf Of
>>>>>>>>>>> *Erik Rissanen
>>>>>>>>>>> *Sent:*
Thursday, October 04, 2012 4:42 AM
>>>>>>>>>>> *To:*
>>>>>>>>>>> <mailto:>
>>>>>>>>>>> <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%20Profil
>>>>>>>>>>> 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
>>>>>>>>>>> <http://www.quest.com>
<http://www.quest.com>
