Re: [xacml] Issues Relating to Obligations

[Steven Legg <steven.legg@viewds.com>]

Hi Mohammad,

On 9/03/2013 3:39 AM, Mohammad Jafari wrote:
> Hi David,
>
>  > I would say that if the policy is permit overrides, then a permit with no obligations (e.g. from Alice)
> should not require the obligations of a second permit (e.g. from Bob) to be
>
>  > executed. So this would not produce the result you want.
>
> Why? “Permit-overrides” only specifies how the authorization decisions of the underlying rules/policies are
> to be combined. The obligation-combination behavior should be orthogonally configurable.
>
> Moreover, “permit-overrides” does not specify **which** one of the permitting rules/policies override, so,
> when two underlying elements permit, how do you specify which obligation to return? For example, in a
> permit-override policy, Alice’s Rule and Bob’s Rule both decide to permit, each with different obligations,
> which one’s obligations must be returned? Note that if the answer is to rely on the order of appearance in
> the XML code, that just makes things more complicated (I explained this:
> https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201302/msg00015.html)
>
> I understand how the PDP currently works, but I am trying to show it is not enough for handling obligations.
> I also understand that there might be workarounds to create the expected behavior in this or that example,
> but I believe this is a general issue.

I agree with you there. I also have a particular problem with obligations on administrative
policies. The reduction algorithm doesn't need to continue once it finds a Permit from
an authorizing administrative policy, which means that obligations on other authorizing
policies are ignored. In this case I don't even have the luxury of choosing a different
combining algorithm, not that such a choice is a solution in the general case where one
wants to ensure that all relevant obligations are returned whether the overall result is
Permit or Deny.

However, this is not the only problem with obligations resulting from their close-coupling
with policies. Suppose that I want to send an alert every time a particular resource is
updated. It is not unreasonable to have a rule that grants both query and update access
to the resource for a particular group of users. However, I can't create such a rule and
add the obligation to it because then the obligation would be returned even if a member
of that user group was only querying the resource. I would have to create two rules: one
for querying and one for updating. It isn't necessarily the case that the situation
under which a particular obligation needs to be returned will be perfectly aligned with
the situation under which a particular rule is applicable, but the current design forces
it to be so.

In order to address both of the above concerns I have implemented what I've called an
Obligation and Advice Authority (OAA), which allows the decoupling of the obligation
and advice processing from the policy evaluation. The basic idea is that the context
handler first evaluates a request to obtain a decision, and then using the original
request and the resulting decision, asks the OAA for relevant obligations and advice
(to be added to any obligations or advice that may have been returned with the decision).

At a minimum, the OAA needs each obligation or advice, or related group of obligations
and advice, to be associated with a condition that determines the situations under
which the obligations or advice are applicable. Rather than create new structures to
represent this association, I just used XACML rules and policies and existing
processing models. Thus the OAA is just another PDP with a bunch of Obligation and
Advice (OA) Policies (in the ViewDS implementation it is the same PDP, but the regular
policy and OA policy are partitioned). The context handler takes the decision from the
regular PDP, turns it into an attribute (Category="http://viewds.com/xacml/decision-info";,
AttributeId="http://viewds.com/xacml/decision-info/decision";, DataType string and
attribute value "Permit", "Deny", "Indeterminate" or "NotApplicable"), adds the
attribute to the original request context and presents this new request to the OAA PDP.
If the result from the OAA is Permit, then any obligations or advice with that
result are added to the result from the regular PDP, which is then returned to the PEP.
If the result from the OAA is Indeterminate, then the overall result is Indeterminate.
If the result from the OAA is Deny or NotApplicable, then the result from the regular
PDP is returned to the PEP unaltered.

A typical OA rule has the obligations or advice of interest, Permit as the effect, an
XACML condition that describes the situation in which the obligations or advice are
applicable, FulfillOn/AppliesTo of "Permit" and a target that matches the
decision-info.decision attribute to one or more of the values "Permit", "Deny",
"Indeterminate" or "NotApplicable". Note that in an OA rule it is this target that
takes over the role of the FulfillOn and AppliesTo XML attributes. To ensure that
all relevant obligations and advice are always returned I only have to combine all
the OA rules/policies using deny-overrides.

With the OAA, I can quite easily write a single OA rule that returns an obligation
when a nominated resource is updated, regardless of whichever and how many regular
policies there are that grant update and/or query access to the resource. I can also
force obligations to be returned with decisions determined by delegates' policies
without having to put those obligations on the authorizing policies.

If I want to I can return obligations or advice with Indeterminate or NotApplicable
decisions, for example, to raise an alert if there is any attempt to access a specific,
protected resource regardless of the outcome of that attempt.

> My suggestion is:
> -As a short-term solution, we define a profile of obligation-sensitive combining algorithms to support this.
>
> -As a long-term solution (maybe in the vision for XACML-4.0), we consider supporting two separate combing
> functions for obligation and authorization decisions at the PolicySet and Policy level.

The OAA is a more comprehensive short-term solution.

Regards,
Steven

> Regards,
>
> Mohammad
>
>  > On the other hand if the policy is deny overrides, then Bob can decide to either forbid all access, or
> grant access with his obligation. In the latter case his obligation will be executed if Alice grants access
> with no obligations.
>
>  >
>
>  >So Erik would appear to be correct
>
>  >
>
>  >regards
>
>  >
>
>  >David
>
> On 08/03/2013 03:28, Mohammad Jafari wrote:
>
>  >  > 3. Another issue I am trying to remember is the question that
>
>  > current combining methods allow applicable policies and rules to be
>
>  > skipped if the value of the Effect can be determined without them.
>
>  > This means that some Obligations in applicable policies may not be
>
>  > discovered. This was debated extensively in the old days. (I am and
>
>  > was firmly in the optimized evaluation camp.) My recollection of the
>
>  > final resolution was that thru the proper choice of combining methods,
>
>  > it is possible to force all policies to be evaluated. Does anyone know if this is true?
>
>  > Bill or anybody else do you remember this debate and its outcome?
>
>  >
>
>  > Yes, you can use combining algorithms to do this. If you have a
>
>  > policies with obligations for a permit decision for instance, you can
>
>  > use a deny-overrides algorithm to collect them all, since this will
>
>  > continue processing all policies even if it finds a permit decision.
>
>  > Conversely you can collect deny obligations with a permit-overrides.
>
>  >
>
>  > I know that this might work but I don’t think it’s a good idea.
>
>  >
>
>  > First, what if one wants to have a /permit-overrides/ behavior for
>
>  > authorization decisions but collect all applicable obligations? The
>
>  > obligation- and authorization-combining behavior should be expressible
>
>  > separately and independent of each other.
>
>  >
>
>  > An example use-case: consider a record containing psychology notes
>
>  > resulting from a couple counseling for Alice and Bob with doctor
>
>  > Charlie. Now suppose that Alice and Bob eventually break up and Alice
>
>  > wants to continue counseling with a second doctor Doris.
>
>  >
>
>  > The overall policy is that the consent of either of the clients
>
>  > involved in the counseling is enough to grant access to the notes to a
>
>  > second psychologist (permit-overrides). On the other hand, Bob’s
>
>  > consent includes an obligation to redact his personally identifiable
>
>  > information (name and address) from the notes for any doctor other
>
>  > than his own psychologist. So, we need a permit-override behavior and
>
>  > yet we need to combine all the obligations.
>
>  >
>
>  > Also, I think using the combing algorithms like that is essentially
>
>  > “tricking” the PDP to process the obligations in a certain way based
>
>  > on the side-effects of an authorization combining algorithm on obligations.
>
>  > I think it is not desirable to rely on a implications like that and it
>
>  > is better for the policy readability to rely on explicit parameters
>
>  > that tell the PDP how to process obligations and authorization
>
>  > decisions from the underlying elements.
>
>  >
>
>  > Regards,
>
>  >
>
>  > Mohammad
>
>  >
>
>  > Best regards,
>
>  >
>
>  > Erik
>
>  >
>
>  >  > Hal
>
>  >
>
>  >  >
>
>  >