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



Danny,

If I were serious about supporting dynamic template reduction I would take
a different approach, drawing on capabilities that would have more general
uses.

We would need to iterate over the parameter groups. You may recall a
message I wrote on the xacml-comment list describing iterators in the
form of new ForAny and ForAll expressions. Those expressions iterate over
a collection of attribute values. A parameter group is effectively a group
of attributes, so we would need a new concept of a compound attribute value
to iterate over. That is, an attribute value of a new data type that allows
it to contain a nested collection of XACML attributes. The final new bit is
a function that can extract a specified nested attribute from a compound
attribute value.

Each policy template data becomes a single compound attribute value stored
by the PIP. The parameter values for a policy template data are XACML
attributes nested in that compound attribute value. The entire collection
of policy template data is a single XACML attribute containing the compound
attribute values, which the PDP can fetch from the PIP by evaluating a
single attribute designator once.

Instead of a policy template, there is a single policy that uses ForAny
(or ForAll) to iterate over the collection of compound attribute values,
extracting nested attributes from the current compound attribute value
as required as it evaluates the pertinent sub-expression in each iteration.

A limitation is that the iterators can only operate within a condition,
so the "template" has to be described in a single expression, whereas a
Policy Template Engine could expand a template policy or even a template
policy set. I don't think that is showstopper, and is adequate for the
current examples, but may be inconvenient at times.

So there you have it. For the cost of two new expressions, one new data-type
and one new function (and no protocol extensions) I could reproduce the
effect of dynamic template reduction.

I can expand on these ideas if anyone is interested, though I don't expect
there is much interest in dynamic template reduction. I mention them only
because some folks may find some of these things useful in other contexts.
I originally described ForAny and ForAll as a way of properly handling
multi-valued attributes in XACML. Compound attribute values I thought about in
the context of IPC and EC-US where there is a problem correlating multi-valued
attributes. For example, organization could be a compound attribute where
each primary organization value can have its relationship to the subject or
the subject's organization described by nested attributes.

Regards,
Steven

On 10/10/2012 1:03 PM, Danny Thorpe wrote:

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.
<<<

Agreed.

My point was *if* there were some way for the PIP to figure out at PDP auth request evaluation time what policy template + data combination was intended for the current context, then the PIP should be able to return the appropriate parameter data set.  Looking for an indicator in the request is one idea. Looking for an indicator in the policy ID is another idea.

However, since manipulating the policy ID basically requires copying the policy content for each distinct set of parameter data, this is no better than static reduction - and a lot more complex.

Storing a unique identifier of a parameter data set in an XML attribute on the <Policy/Set> element is another way to provide an indicator to the PIP, assuming the PIP can see what policy the PDP is evaluating at the moment of <AttributeDesignator> evaluation. However, this still requires policy replication per distinct parameter dataset, no better than static reduction.

Unless a useful indicator to the PIP of what parameter dataset applies to the current context can be found, I don't see that dynamic evaluation of policy template parameter data using <AttributeDesignator> in the existing XACML policy structure is feasible.

What the PIP really needs to know is that the current policy is the pairing of a policy (template) and a parameter data set. The PDP only needs the policy part, and only a single instance of the policy is needed if the binding of the parameter data to the policy is defined outside of the policy - such as in a policy reference, for example.  Extend <PolicyIdReference> (IdReference, actually) with an additional attribute(s) or child element(s) indicating parameter data set(s) to apply to the referenced policy. But this is again heading "into the weeds" requiring new infrastructure and new data flow between subsystems in the PDP cloud.

So we're left with static reduction of policy templates + parameter data generating simple policies, replacing particular <AttributeDesignator> with bags of corresponding parameter values in <Condition> expressions but not in <Match> expressions.

-Danny

Danny Thorpe
Authorization Architect
Dell | Identity & Access Management, Quest Software

Quest Software is now part of Dell.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@viewds.com]
Sent: Tuesday, October 09, 2012 6:29 PM
To: Danny Thorpe
Cc: Jean-Paul Buu-Sao; Erik Rissanen; xacml@lists.oasis-open.org
Subject: Re: [xacml] Updated policy template wiki


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-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</Attribut
eV
alue>

            <AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string";>Packard</Attribu
teV
alue>

          </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</Attribut
eV
alue>

            <AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string";>Spad</Attribute
Valu
e>

          </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: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]