OASIS eXtensible Access Control Markup Language (XACML) TC

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

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

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

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 >

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

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 >

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

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 >

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

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

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

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

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 >

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

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

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

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 >

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

Yes, your example makes sense mechanically. I believe that the motivation to require the negation was the initial TC design stipulation that Policy/PolicySets may be processed in an arbitrary order and still arrive at the same decision. I assume that the intent here is to also remove that constraint? thanks b On May 22, 2013, at 7:21 AM, Erik Rissanen <erik@axiomatics.com> 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 >

Policy/PolicSets that are peers within the same container can be evaluated in any order under unordered combining algorithms. It does appear that this on-permit-apply-second would need to be classified as an ordered combining algorithm, with all the implementation restrictions that entails. -Danny Danny Thorpe Authorization Architect Dell Identity & Access Management Quest Software is now part of Dell. >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of William Parducci > Sent: Wednesday, May 22, 2013 1:14 PM > To: Erik Rissanen > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] Generalizing on-permit-apply-second > > Yes, your example makes sense mechanically. I believe that the motivation > to require the negation was the initial TC design stipulation that > Policy/PolicySets may be processed in an arbitrary order and still arrive at the > same decision. I assume that the intent here is to also remove that > constraint? > > thanks > > b > > On May 22, 2013, at 7:21 AM, Erik Rissanen <erik@axiomatics.com> 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

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

Hi Steven, I haven't thought about the details yet. Superficially it's deny or N/A which would cause the third policy to be evaluated, but I haven't thought about all the corner cases and their implications. I would prefer that the whole policy set is indeterminate if it's ambiguous which child gets evaluated, rather than combining both of them. The point is to be able to select on and only one of the children using a condition. Combining them both in case of errors contradicts the original requirement. I'll think a bit more about this issue. You might have already figured it out though. ;-) Best regards, Erik On 2013-05-23 02:04, Steven Legg wrote: 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

Have you considered the mechanism to handle Policyset application conflicts, or the result should it happen? Thanks b On May 23, 2013, at 12:14 AM, Erik Rissanen <erik@axiomatics.com> wrote: > Hi Steven, > > I haven't thought about the details yet. Superficially it's deny or N/A which would cause the third policy to be evaluated, but I haven't thought about all the corner cases and their implications. > > I would prefer that the whole policy set is indeterminate if it's ambiguous which child gets evaluated, rather than combining both of them. The point is to be able to select on and only one of the children using a condition. Combining them both in case of errors contradicts the original requirement. > > I'll think a bit more about this issue. You might have already figured it out though. ;-) > > Best regards, > Erik > > On 2013-05-23 02:04, Steven Legg wrote: >> >> 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 > > > --------------------------------------------------------------------- > 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

Hi Bill, I don't see how that could happen, or what do you mean? Best regards, Erik On 2013-05-23 15:43, Bill Parducci wrote: Have you considered the mechanism to handle Policyset application conflicts, or the result should it happen? Thanks b On May 23, 2013, at 12:14 AM, Erik Rissanen <erik@axiomatics.com> wrote: Hi Steven, I haven't thought about the details yet. Superficially it's deny or N/A which would cause the third policy to be evaluated, but I haven't thought about all the corner cases and their implications. I would prefer that the whole policy set is indeterminate if it's ambiguous which child gets evaluated, rather than combining both of them. The point is to be able to select on and only one of the children using a condition. Combining them both in case of errors contradicts the original requirement. I'll think a bit more about this issue. You might have already figured it out though. ;-) Best regards, Erik On 2013-05-23 02:04, Steven Legg wrote: 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 --------------------------------------------------------------------- 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

If there is a condition in any given PolicySet that could preclude the inclusion of any another PolicySet, it seems that there would be the possibility of conflict. I have not thought about this in depth, but it seems possible that PolicySet A could have a condition that fires excluding PolicySet B which concurrently has a condition that fires, excluding PolicySet A. b On May 23, 2013, at 6:59 AM, Erik Rissanen <erik@axiomatics.com> wrote: > Hi Bill, > > I don't see how that could happen, or what do you mean? > > Best regards, > Erik > > On 2013-05-23 15:43, Bill Parducci wrote: >> Have you considered the mechanism to handle Policyset application conflicts, or the result should it happen? >> >> Thanks >> >> b >> >> On May 23, 2013, at 12:14 AM, Erik Rissanen <erik@axiomatics.com> wrote: >> >>> Hi Steven, >>> >>> I haven't thought about the details yet. Superficially it's deny or N/A which would cause the third policy to be evaluated, but I haven't thought about all the corner cases and their implications. >>> >>> I would prefer that the whole policy set is indeterminate if it's ambiguous which child gets evaluated, rather than combining both of them. The point is to be able to select on and only one of the children using a condition. Combining them both in case of errors contradicts the original requirement. >>> >>> I'll think a bit more about this issue. You might have already figured it out though. ;-) >>> >>> Best regards, >>> Erik >>> >>> On 2013-05-23 02:04, Steven Legg wrote: >>>> 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 >>> >>> --------------------------------------------------------------------- >>> 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 >

Hi Bill, On 24/05/2013 1:58 AM, Bill Parducci wrote: If there is a condition in any given PolicySet that could preclude the inclusion of any another PolicySet, it seems that there would be the possibility of conflict. I have not thought about this in depth, but it seems possible that PolicySet A could have a condition that fires excluding PolicySet B which concurrently has a condition that fires, excluding PolicySet A. The only way I can see that being possible is if the policy sets include each other by reference, either directly or indirectly. Such a construction is an error according to the XACML core. As children of the same policy set with the on-permit-apply-second combining algorithm, only the first child has the power to exclude the second and/or third child. The second and third children can't exclude each other or the first child. Steven b On May 23, 2013, at 6:59 AM, Erik Rissanen <erik@axiomatics.com> wrote: Hi Bill, I don't see how that could happen, or what do you mean? Best regards, Erik On 2013-05-23 15:43, Bill Parducci wrote: Have you considered the mechanism to handle Policyset application conflicts, or the result should it happen? Thanks b On May 23, 2013, at 12:14 AM, Erik Rissanen <erik@axiomatics.com> wrote: Hi Steven, I haven't thought about the details yet. Superficially it's deny or N/A which would cause the third policy to be evaluated, but I haven't thought about all the corner cases and their implications. I would prefer that the whole policy set is indeterminate if it's ambiguous which child gets evaluated, rather than combining both of them. The point is to be able to select on and only one of the children using a condition. Combining them both in case of errors contradicts the original requirement. I'll think a bit more about this issue. You might have already figured it out though. ;-) Best regards, Erik On 2013-05-23 02:04, Steven Legg wrote: 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 --------------------------------------------------------------------- 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

On May 23, 2013, at 5:23 PM, Steven Legg <steven.legg@viewds.com> wrote: > > Hi Bill, > > On 24/05/2013 1:58 AM, Bill Parducci wrote: >> If there is a condition in any given PolicySet that could preclude the inclusion of any another PolicySet, it seems that there would be the possibility of conflict. I have not thought about this in depth, but it seems possible that PolicySet A could have a condition that fires excluding PolicySet B which concurrently has a condition that fires, excluding PolicySet A. > > The only way I can see that being possible is if the policy sets include > each other by reference, either directly or indirectly. Such a construction > is an error according to the XACML core. > > As children of the same policy set with the on-permit-apply-second combining > algorithm, only the first child has the power to exclude the second and/or > third child. The second and third children can't exclude each other or the > first child. > > Steven Ok. So to make sure that I am fully grasping this, the proposal is that this new mechanism only applies to PolicySets (not Policies) and that these PolicySets will have a new requirement that Policy order is required to be maintained within them. Is this correct? thanks b

Hi Bill, On 24/05/2013 10:35 AM, William Parducci wrote: On May 23, 2013, at 5:23 PM, Steven Legg <steven.legg@viewds.com> wrote: Hi Bill, On 24/05/2013 1:58 AM, Bill Parducci wrote: If there is a condition in any given PolicySet that could preclude the inclusion of any another PolicySet, it seems that there would be the possibility of conflict. I have not thought about this in depth, but it seems possible that PolicySet A could have a condition that fires excluding PolicySet B which concurrently has a condition that fires, excluding PolicySet A. The only way I can see that being possible is if the policy sets include each other by reference, either directly or indirectly. Such a construction is an error according to the XACML core. As children of the same policy set with the on-permit-apply-second combining algorithm, only the first child has the power to exclude the second and/or third child. The second and third children can't exclude each other or the first child. Steven Ok. So to make sure that I am fully grasping this, the proposal is that this new mechanism only applies to PolicySets (not Policies) Correct. The on-permit-apply-second combining algorithm is only defined as a policy combining algorithm. and that these PolicySets will have a new requirement that Policy order is required to be maintained within them. Is this correct? Yes, the order is significant (even in the current draft). Regards, Steven thanks b

On May 23, 2013, at 6:05 PM, Steven Legg <steven.legg@viewds.com> wrote: >> Ok. So to make sure that I am fully grasping this, the proposal is that this new mechanism only applies to PolicySets (not Policies) > > Correct. The on-permit-apply-second combining algorithm is only defined as a > policy combining algorithm. > > and that these PolicySets will have a new requirement that Policy order is required to be maintained within them. Is this correct? > > Yes, the order is significant (even in the current draft). Thanks Steven. I believe this marks a bit of a shift in our approach as it the first situation where there is different processing logic between Policy and PolicySet and the requirement for order of Policy processing. b

Order of policy processing is already imposed by the existing Ordered-Deny-Overrides, Ordered-Permit-Overrides, and First-Applicable policy combining algorithms. -Danny Danny Thorpe Authorization Architect Dell Identity & Access Management Quest Software is now part of Dell. >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Bill Parducci > Sent: Thursday, May 23, 2013 10:30 PM > To: Steven Legg > Cc: Erik Rissanen; xacml@lists.oasis-open.org > Subject: Re: [xacml] Re: "else" is what ? Was:Re: [xacml] Generalizing on- > permit-apply-second > > > On May 23, 2013, at 6:05 PM, Steven Legg <steven.legg@viewds.com> > wrote: > > >> Ok. So to make sure that I am fully grasping this, the proposal is > >> that this new mechanism only applies to PolicySets (not Policies) > > > > Correct. The on-permit-apply-second combining algorithm is only > > defined as a policy combining algorithm. > > > > and that these PolicySets will have a new requirement that Policy order is > required to be maintained within them. Is this correct? > > > > Yes, the order is significant (even in the current draft). > > Thanks Steven. I believe this marks a bit of a shift in our approach as it the > first situation where there is different processing logic between Policy and > PolicySet and the requirement for order of Policy processing. > > b > > > --------------------------------------------------------------------- > 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

I stand corrected. My reticence to having an if/then construct remains, but I seem alone in this position so I will refrain from pursuing further. b On May 24, 2013, at 9:41 AM, Danny Thorpe <Danny.Thorpe@software.dell.com> wrote: > Order of policy processing is already imposed by the existing Ordered-Deny-Overrides, Ordered-Permit-Overrides, and First-Applicable policy combining algorithms. > > -Danny > > Danny Thorpe > Authorization Architect > Dell Identity & Access Management > > Quest Software is now part of Dell. > >>
Original Message----- >> From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On >> Behalf Of Bill Parducci >> Sent: Thursday, May 23, 2013 10:30 PM >> To: Steven Legg >> Cc: Erik Rissanen; xacml@lists.oasis-open.org >> Subject: Re: [xacml] Re: "else" is what ? Was:Re: [xacml] Generalizing on- >> permit-apply-second >> >> >> On May 23, 2013, at 6:05 PM, Steven Legg <steven.legg@viewds.com> >> wrote: >> >>>> Ok. So to make sure that I am fully grasping this, the proposal is >>>> that this new mechanism only applies to PolicySets (not Policies) >>> >>> Correct. The on-permit-apply-second combining algorithm is only >>> defined as a policy combining algorithm. >>> >>> and that these PolicySets will have a new requirement that Policy order is >> required to be maintained within them. Is this correct? >>> >>> Yes, the order is significant (even in the current draft). >> >> Thanks Steven. I believe this marks a bit of a shift in our approach as it the >> first situation where there is different processing logic between Policy and >> PolicySet and the requirement for order of Policy processing. >> >> b >> >> >> --------------------------------------------------------------------- >> 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 >

Correction: Create an abstract RESOURCE that is instantiated by an Obligation. b

Hi Erik, On 21/05/2013 5:19 PM, 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. I'm not against it. Your original suggestion to generalize the on-permit-apply-second algorithm seems reasonable to me, though a different name may be more appropriate (if-then-optional-else ?). 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 I'm not so sure this further generalization is a good idea. Policies/Policy sets 1, 3, 5, 7, etc. are the conditions, and policies/policy sets 2, 4, 6, 8, etc. are the policy selected to be evaluated. It would be really easy for a policy writer to screw up the evaluation of the overall policy set by an inappropriate insertion or deletion because there is no clear distinction between the even numbered items and the odd numbered items. The same effect can be achieved with nested, generalized on-permit-apply-second. PolicySet on-permit-apply-second Policy - Rule - Condition A PolicySet -> used if A was true PolicySet on-permit-apply-second -> used if A was false Policy - Rule - Condition B PolicySet -> used if B was true PolicySet on-permit-apply-second -> used if B was false Policy - Rule - Condition C PolicySet -> used if C was true PolicySet -> used if C was false It means a bit more policy set wrapping, but is more robust and easier to follow. Regards, Steven 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

Hi Steven, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Steven Legg > Sent: Wednesday, May 22, 2013 9:11 AM > To: Erik Rissanen > Cc: Bill Parducci; xacml@lists.oasis-open.org > Subject: Re: [xacml] Generalizing on-permit-apply-second > > It means a bit more policy set wrapping, but is more robust and easier to follow. I don't agree with that statement. There is a reason most programming languages have a "switch" or "case" construct in addition to "if". Thanks, Ray

Hi Ray, On 22/05/2013 5:31 PM, Sinnema, Remon wrote: Hi Steven,
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Steven Legg Sent: Wednesday, May 22, 2013 9:11 AM To: Erik Rissanen Cc: Bill Parducci; xacml@lists.oasis-open.org Subject: Re: [xacml] Generalizing on-permit-apply-second It means a bit more policy set wrapping, but is more robust and easier to follow. I don't agree with that statement. There is a reason most programming languages have a "switch" or "case" construct in addition to "if". Yeah, but those languages have a syntax to introduce the various parts of the construct. All we have in a policy set is a list of policies and policy sets (and references to same). The part each plays in the "switch" construct is solely determined by position. Go to any policy in a big policy set and you won't know what part it plays except by counting back to the beginning. At least with nested on-permit-apply-second one only needs to count to three at most. We're also talking about something more general that a switch or case because we are applying a test at each second policy. It's more like: if condition A policy set 2 else if Condition B policy set 4 else if Condition C policy set 6 ... else policy set N than switch (condition) case 1: policy set 2 case 2: policy set 4 case 3: policy set 6 ... default: policy set N Regards, Steven Thanks, Ray