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: "else" is what ? Was:Re: [xacml] Generalizing on-permit-apply-second



Hi Erik,

In the current draft the second child is evaluated if the first child
evaluates to Permit, Indeterminate{P} or Indeterminate{DP}. In the extension
to if-then-else, what decision(s) from the first child would cause the
third child to be evaluated ?

Equivalence to your "today" example would mean that we evaluate both the
second and third children and combine the results if the first child evaluates
to Indeterminate{P} or Indeterminate{DP}. We evaluate the third child and
not the second child when the first child evaluates to NotApplicable.

Regards,
Steven

On 23/05/2013 12:21 AM, Erik Rissanen wrote:
Hi Bill,

You did not understand me. What I am saying is that because there is no combining algorithm like the one I
am proposing, one has to use a redundant condition to prevent the second policy to be evaluated. Today you
have to do 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)

Note the line saying "Condition not(foo)". It is there to prevent policy set B to be evaluated in the case
the condition foo is true, but policy set A is NotApplicable. I want instead to write:

PolicySet [on-permit-apply-second]
  Policy
    Rule
      Condition foo
  PolicySet
      -> some content A (the "then" branch)
  PolicySet
      -> some content B (the "else" branch)

Regarding use cases, I think it's a valid requirement to be able to use an arbitrary condition to choose
between two arbitrary policies. This shows up often and there is no convenient way to do it today.

Best regards,
Erik

On 2013-05-22 15:54, Bill Parducci wrote:
Not to be pedantic, but that is an implementation not a use case. I understand that you cannot divulge
proprietary information so I will not press further. That said, the concept of using a condition from one
policy set to negate ("protect") another seems wrong to me. Perhaps I am alone in this perception. I would
be interested in knowing how this is arbitrated when numerous policy sets each negate the other.

Thanks

b

On May 21, 2013, at 11:45 PM, Erik Rissanen <erik@axiomatics.com> 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 <erik@axiomatics.com> 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 <erik@axiomatics.com> 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 <erik@axiomatics.com> 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 <erik@axiomatics.com> 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 <erik@axiomatics.com> 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 <erik@axiomatics.com> 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



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