Re: [xacml] Generalizing on-permit-apply-second
Allan,
Yes, that is true. That is what I wrote in my initial email, so
yes, it's syntactic sugar.
But there is value in it because it simplifies tooling
implementation. It's an implementation overhead to have to do the
refactoring when outputting policies or to have to scan for these
redundancies when round tripping back a policy into the PAP in
order to hide them from the user.
And it also simplifies the PDP implementation from a performance
point of view since we avoid the redundant expressions at run
time. Sure, the PDP could scan for redundancy like this, but then,
that's another thing we can avoid having to implement.
Best regards,
Erik
On 2013-05-22 13:07, Allan Foster wrote:
Erik, It seems to me that this basically ends up
being Syntacic sugar.
The reason I say this, is that it is quite
possible in XACML to have multiple policies or even multiple
policy sets all being evaluated for a result.
If (someCondition)
then policyA
else PolicyB
is exactly the same as
PolicyA <...> Condition (SomeCondition)
PolicyB <....> Condition (Not SomeCondition)
What is your requirement to have them as a single
policy? Why cant two policies with different conditions
achieve the same end result.
A smart front end editor can easily refactor the
first into the second and vice versa
Allan
On Tue, May 21, 2013 at 11:45 PM, Erik
Rissanen <>
wrote:
Hi Bill,
Yes, I already did: "if condition foo is true then use
policy set A for making the decision, otherwise use policy
set B"
I have many customers who have requirements in this form:
some set of conditions which depend on the subject or
resource or a combination of both, which determine which
policy set applies. It could be about for instance different
government regulations which apply in different cases
depending on the subject/resource.
I cannot be more specific for two reasons, 1)
confidentiality of customer data, 2) the specific use cases
really are very diverse, but they all have the same form,
that is, to choose among different policies based on a set
of conditions.
The reason that it works poorly in XACML today is that all
combining algorithms (except only-one-applicable)
"backtrack" out from policy set A if it turns out to be N/A.
However, in these cases the customer wants to make sure that
policy B is never applied if the correct policy is policy A.
The problem can be solved by "protecting" policy B with the
negation of condition "foo", but that leads to redundancy in
policies, which puts an overhead on either authors or tools
to manage it.
Best regards,
Erik
On 2013-05-21 18:40, Bill Parducci wrote:
Can you provide an example of your use case?
thanks
b
On May 21, 2013, at 9:16 AM, Erik Rissanen <> wrote:
Hi Bill,
Ok, I understand what you mean, but that is not the use
case I am trying to solve. What you say is a vastly
restricted subset of the general requirement "if
condition foo is true then use policy set A for making
the decision, otherwise use policy set B".
It could be something like "if the subject is an
internal employee or an external person with temporary
clearance for internal access, use the internal
need-to-know policy (which is very complex), otherwise
use the policy for external information sharing
regulations compliance (which is also very complex)"
It's only rarely that you can qualify the resource into
a partition of classes like in your example.
Best regards,
Erik
On 2013-05-21 18:00, Bill Parducci wrote:
Before we dive down into the syntactical weeds I
suggest we look at this from a simpler perspective. I
see it something like this:
Bob requests access to Resource Foo. Foo exists in 3
flavors: FooBronze, FooSilver, FooGold. The PEP
generates a request to the PDP for Bob to access Foo.
(Note that the request has no references to the
instances of Foo.) The PDP performs whatever level of
complex processing that the language allows. Assume
the decision is Permit and there is an Obligation tied
to some attribute of Bob (or time of day, network
speed, concurrency, behavior, etc.) This Obligation
states OnPermit::Foo:FooSilver. The answer the PEP
receives is Permit;Foo:FooSilver. It then grants Bob
access to Resource FooSilver.
This requires that the PEP has the ability to process
an abstract Resource, which implies a non-linear
access control mechanism (routing, redirection, etc.
vs. "locked gate"), which may or may not apply to the
system you are describing. It is a common mechanism
for solving such problems which is why I am throwing
it out there. A "whitebox" understanding of the
decision process with the PDP as currently defined
this aspect is not new and this solution doesn't
require the PDP to have any understanding whatsoever
of the decision making process itself.
Does that make sense?
b
On May 21, 2013, at 8:25 AM, Erik Rissanen <>
wrote:
Hi again Bill,
To add more thing. The reason I don't understand how
obligations relate to this is that obligations are
processed on the PEP side. I want the "if condition
foo is true then use policy set A for making the
decision, otherwise use policy set B" to happen on
the PDP. So I cannot see that there is any way an
obligation can impact this, unless you intend
somehow to defer policy evaluation to the PEP side.
Also keep in mind in your example that "foo",
"policy set A" and "policy set B" can be arbitrarily
complex. I just used the role example to keep the
example size small.
Best regards,
Erik
On 2013-05-21 17:17, Erik Rissanen wrote:
I don't understand how an obligation can solve
what I perceive as a missing feature in the policy
evaluation logic.
Basically, what I see is that customers have
requirements that say "if condition foo is true
then use policy set A for making the decision,
otherwise use policy set B".
Could you elaborate in more detail in pseudo code
XACML how your solution works? I do not understand
what you wrote. Could you specify it with policy
set structure and combining algorithms?
Erik
On 2013-05-21 17:08, Bill Parducci wrote:
I suggested a more general solution in my first
note that I don't think will require a core
schema change: Create an abstract Action that is
instantiated by an Obligation. That should
address your issue as well provide a more robust
solution than if/then, if/then, if/then,
if/then, if/then... without the need to embed
ordered Boolean logic chains within rule sets.
I'd be happy to discuss the idea with your in
more detail to see if it might solve this issue
as described.
You are free to create and propose whatever you
would like. However, what Axiomatics chooses to
build outside of the spec is not really relevant
to this list.
b
On May 21, 2013, at 12:19 AM, Erik Rissanen <>
wrote:
Sure, I can see how a more general switch type
of _expression_ could be useful, but that does
not mean that an if-then-else is not useful in
itself. I can see a big need for it from
customer deployments. And I don't want to do
core schema changes, so a combining algorithm
extension will work nicely.
If the TC is against it in the combining
algorithms profile, I'll just do a custom
Axiomatics extension for this. It's important
enough for me.
What would you suggest as the more general
solution? The on-permit-apply-second could be
generalized even further so it can take a
number of pairs of policies as children, like
this:
PolicySet on-permit-apply-second
Policy - Rule - Condition A
PolicySet -> used if A was true
Policy - Rule - Condition B
PolicySet -> used if B was true
Policy - Rule - Condition C
PolicySet -> used if C was true
... etc
Optionally there can be a final single child
which will be used as the "else" case if
nothing else matched. I think this should
solve the more general case you are pointing
to.
Best regards,
Erik
On 2013-05-20 18:14, Bill Parducci wrote:
Your are proposing if/then but I still
maintain that the use case is unnecessarily
limiting. A simple A|B Boolean construct
being added doesn't address what I believe
is the underlying A|B|C (D|E|F...) issue to
be solved.
It seems that Policy authors would only be
affected in either solution via the
implementation of the client facing editor.
Since there isn't any branching logic in the
spec now any change would by definition be
new.
I believe that if we are going to go through
the effort of getting something like this
standardized we should consider taking the
more generalized approach.
b
On May 19, 2013, at 11:51 PM, Erik Rissanen
<>
wrote:
Hi,
I am asking for an explicit "if-then-else"
into XACML. "if-then-else" is often how
people formulate their access policy
requirements and it's an overhead for them
to have to re-factor the requirement into
some other form of _expression_.
Best regards,
Erik
On 2013-05-17 17:03, Bill Parducci wrote:
I am not suggesting that the outcomes be
expanded. I am saying that it appears
your are effectively asking for a
polymorphic Resource that is bound to a
Subject. The Action is unchanged re:
access control. An if/then mechanism is
not the way I would handle it. What if
you want to differentiate between senior
employees or admins vs. general
employees or others? The solution
becomes unwieldy.
Subject: user employee
PolicySet 1 -> Permit/Deny (on
abstract Resource); Obligation 1
(Resource instance 1)
Subject: user manager
PolicySet 1 -> Permit/Deny (on
abstract Resource); Obligation 2
(Resource instance 2)
Subject: user admin
PolicySet 1 -> Permit/Deny (on
abstract Resource); Obligation 3
(Resource instance 3)
[...]
No boolean machinery is needed.
b
On May 17, 2013, at 7:30 AM, Erik
Rissanen <>
wrote:
Hi Bill,
I don't see any relation to
obligations at all. I'm simply
thinking of things like:
if "user is employee" then
PolicySet 1
-> policies about employees go
here
else
PolicySet 2
-> policies about all other
kinds of users go here
This is for making the decision
regarding Permit/Deny. It's not about
expanding the possible outcomes to a
larger set than Permit/Deny/NA/Indet.
Best regards,
Erik
On 2013-05-17 15:42, Bill Parducci
wrote:
This is a subset of the QoS use case
I have advocated for in the past. I
personally believe that this is best
handled via an Obligation: the
Permit is granted to an abstract
Resource and the Obligation defines
the Resource Instance. This keeps
the decision machinery simple, while
allowing for trinary, quaternary...
decisions rather than being limited
to an if/then construct.
Permit: Resource {foo}
Obligation: foo=>foo1
b
On May 17, 2013, at 12:54 AM, Erik
Rissanen <>
wrote:
All,
I have a suggestion to generalize
the on-permit-apply-second
algorithm.
The problem I see is that it's not
unusual for customers to choose
among policies on a "if then
else"-basis. In other words, if a
condition is true, choose one
policy, otherwise use another
policy.
The problem is that there is no
combining algorithm which does
that currently. Yes, we do have
targets and conditions and
algorithms such as
first-applicable, but there is a
crucial difference between "if
then else" and these combining
algorithms. Consider this case:
PolicySet [first-applicable]
Policy target foo
-> some content A
Policy
-> some content B
Naively this is an attempt to
write an if-then-else type of
policy set. The condition is
"foo". If foo is matching, then
"some content A" is evaluated.
However, the problem is that if
"some content A" itself returns
N/A, then the first-applicable
combining algorithm will evaluate
"some content B". So, even if the
target "foo" is matching, it can
turn out that "some content B" is
used. This is not what "if then
else" means.
There is the only-one-applicable
which is closer to if-then-else,
but it works only on targets, not
on conditions.
The way to model a condition based
if-then-else in XACML today is to
use the on-permit-apply-second and
invert the condition in the "else"
branch. Like this:
PolicySet [first-applicable]
PolicySet
[on-permit-apply-second]
Policy
Rule
Condition foo
PolicySet
-> some content A (the
"then" branch)
PolicySet
[on-permit-apply-second]
Policy
Rule
Condition not(foo)
PolicySet
-> some content B (the
"else" branch)
As you see, it takes a whole lot
of XACML elements to do a simple
if-then-else, which is a very
common use case.
My proposal is to generalize the
on-permit-apply-second algorithm
so it can take a third policy. If
there are only two children, then
it behaves like in the current
spec. However, if there is a third
child, then the third child is
applied if the first policy does
not return permit. Then you can do
the following:
PolicySet [on-permit-apply-second]
Policy
Rule
Condition foo
PolicySet
-> some content A (the
"then" branch)
PolicySet
-> some content B (the
"else" branch)
This is more compact and efficient
and does not contain redundant
expressions.
Let me know if you think this is a
bad idea. Otherwise, I can work
out the details into a new working
draft of the profile.
Best regards,
Erik
---------------------------------------------------------------------
To unsubscribe from this mail
list, you must leave the OASIS TC
that generates this mail. Follow
this link to all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php