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