RE: [xacml] Issues Relating to Obligations

Hi Steven,

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

This seems interesting but it assumes authorization decisions and obligations are orthogonal. So, if they are not in some policy, i.e. if authorization and obligation decisions share
some conditions, it leads to redundancy.

For example, consider the following policies:

P1: “Access is allowed by Alice to File X if it is Monday and access is from outside the local network. On permit produce audit trail type A”.

P2: “Access is allowed by Alice to File X if it is Sunday and access is from within the local network. On permit produce audit trail type B”.

Now, as you see, the mere “permit” is not enough for OAA to tell which rule policy has produced it. Thus, by decoupling these obligations from the authorization policy you have to:

- Repeat the conditions again in the OAA policy.

- Evaluate them twice for every matching request, once in the PDP and once in the OAA.

The former leads to redundancy issues, for example if the policy condition changes from Monday to Tuesday, the admin must change this in two places which is complex and error-prone. The latter leads to performance issues by repeating the same computations twice.

This can be improved by carrying the “policy/rule ID” on which basis the authorization decision has been made to the OAA, but:

- The current PDP specifications don’t support returning the justification for a decision such as the policy/rule ID.

- This somehow couples the obligation to policies which is what you were trying to avoid in the first place.

I think, in general, obligations cannot be decoupled from authorization decisions since there are a lot of examples in which the two are inherently interdependent.

Moreover, I think at a conceptual level, “authorization” is a special case of “obligation” (it’s an obligation telling the PEP to block access completely, or allow it completely). So I believe a general mechanism for combining obligations such as the one I have proposed in the profile will encompass rule-/policy-combining functions that we have right now. I will elaborate this in a short document later and send it to the TC.

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.

Can you explain this use-case further? I am not sure I understand it.

I am thinking of collecting and posting all of these obligation use-cases that are either not supported by the current specifications or need workaround solutions so that we can clarify how good different possible solution are.

Regards,

Mohammad

xacml message