Jean-Paul,
I put in one such example on the wiki page. Search for
"on-permit-apply-second" and you will find it.
Best regards,
Erik
On 2012-10-04 23:01, Jean-Paul Buu-Sao wrote:
Greetings,
Apologies for
missing the call today, as I was in a TSCP event, together
with Gerry and David of Axiomatics.
I have been
much interested in the last findings, and agree that if the
“template” property that we are (all, I think) looking for
could be achieved with standard the
<AttributeDesignator> construct, rather than
introducing new concepts, then this would be for the better.
May I suggest
that, in order to verify this assertion (so to speak), some
folks, such as Erik or Danny, would be kind enough to
propose an alternate proposal to the sample found on our
Wiki (https://wiki.oasis-open.org/xacml/Policy%20Template%20Profile%20Examples)? By the way, as a word of caution,
please disregard the in-correctness of the XCAML 3.0 of
section 1. of the example (yes the devil is in the details,
and David shown me how this example could be made
compliant).
Thanks in
advance,
Jean-Paul
From:
[mailto:] On Behalf Of Danny
Thorpe
Sent: Thursday, October 04, 2012 20:11
To: Erik Rissanen;
Subject: RE: [xacml] Updated policy template wiki
When the
original proposal for policy templates was brought forward,
I noted that simply replacing a single AttributeValue
element with a list of values from the policy template
<Parameter> would fail in <Match> expressions,
since <Match> is very explicit about one value, one
designator/selector. I offered a transform to help produce
valid match expressions.
AttributeDesignator
does provide similar “insert-multiple-values-here”
operations to the policy template substitution behavior, but
I believe the suggestion of policy parameterization came up
because of situations in which AttributeDesignator cannot be
used. Comparing an attribute against a static list of test
values (specific to an organization or location and applied
to a generic policy), for example, is a many-to-many
comparison, but cannot be expressed in a <Match>
element.
As we discussed
on the TC call today, we’re finding more difficulties with
parameter substitution the deeper we dig. Steven Legg noted
in an earlier email that some Xacml functions that take
single <AttributeValue> won’t work if multiple values
are dropped in to replace the <AttributeValue>. This
means some sort of _expression_ transform will be necessary in
condition expressions as well to move policy templates
forward.
In light of
these increasing complexities and challenges, I’m beginning
to agree with you that perhaps the policy template use case
can better be addressed using the existing
<AttributeDesignator>.
This would
mean:
1. Giving up parameterization behavior in
<Match> expressions and moving that logic into
conditions using <AttributeDesignator> to reference an
attribute ID representing the parameterization data.
2. Moving parameterization data from a
static policy generator step to a PIP to fill
<AttributeDesignator> references to a particular
attribute ID with parameterization data in the PDP at auth
request evaluation time.
Using
<AttributeDesignator> instead of policy templates does
impact the use case quite a bit because populating PIP data
is not part of the Xacml spec. Policies could be shared
between organizations per the use case, but how the
parameterization data is applied to those policies would
become a vendor-specific implementation detail.
I can see the
attraction of parameterizing policies to allow up-front
synthesis of specific policies, but as we say “the devil is
in the details.” The details are winning. :/
-Danny
Danny
Thorpe
Authorization
Architect
Dell | Identity
& Access Management, Quest Software
Quest
Software is not part of Dell.
From:
[mailto:]
On Behalf Of Erik Rissanen
Sent: Thursday, October 04, 2012 4:42 AM
To:
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
