OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: 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]