[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Generalizing on-permit-apply-second
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]