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



Erik,

On 9/10/2012 5:32 PM, Erik Rissanen wrote:
Steven,

I am arguing against the whole concept of a template, thus there is no Policy Template Engine in my proposal.

That's what I originally thought, but then I thought maybe you were only
suggesting a syntax for parameters in policy templates, so I asked you
to disregard my response. Seems I was on the right track after all.


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.

I could explain again why this only works in the limited case of one
policy template data per policy template, but you seem to have understood
Jean-Paul's clarification.

FWIW, I expect the Policy Template Engine is either invoked before policies
are imported into the PAP, or is a function of the PAP, so that ordinary
PDPs and PIPs (and even ordinary PAPs) don't have to know about this stuff.

Regards,
Steven


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] *On Behalf Of *Danny Thorpe
*Sent:* Thursday, October 04, 2012 20:11
*To:* Erik Rissanen; 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]> *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>
*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>









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