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,

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
"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</Attribu
teValue>

            <AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string";>Packard</Attribu
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</Attribu
teValue>

            <AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string";>Spad</AttributeV
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: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
<mailto: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
(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:*xacml@lists.oasis-open.org
  [mailto: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
<mailto: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:xacml@lists.oasis-open.org>
  [mailto:xacml@lists.oasis-open.org]
<mailto:[mailto: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
<mailto:xacml@lists.oasis-open.org>
<mailto: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
(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> <http://www.quest.com>



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