Re: [xacml] Issues Relating to Obligations

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

Hi Mohammad,

On 13/03/2013 4:35 AM, Mohammad Jafari wrote:
> 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.

Misaligned rather than completely orthogonal.

The OAA doesn't replace the existing obligation handling. If the users have requirements
where the obligations are perfectly aligned with the authorization decisions, then they
can still attach them to policy sets, policies and rules. When the obligations are
poorly aligned with the targets and conditions of the policy sets, policies and rules
the OAA is available to make the expression of those obligations easier.

> So, if they
> are not in some policy, i.e. if authorization and obligation decisions share
> some conditions, it leads to redundancy.

Well, the ViewDS PAP makes it easy for users to share conditions across many rules and
edit them in one place, so the redundancy doesn't overly concern me. But that's assuming
perfect alignment. When there is poor alignment, the conditions are only similar, to
varying degrees.

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

The policies and the obligations are perfectly aligned in this example, so there is no
need to make use of the OAA.

But might not the obligations actually be more general in this case ? For example, that
on permit, any access from outside the local network uses audit trail type A and that
any access from within the local network uses audit trail type B, regardless of who
is accessing what file on what day. I could express something like that with two OA rules,
but you would need to duplicate the audit trail type obligations on every policy that
allows someone to access some file on some day. That's quite a bit of redundancy.

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

Yes, roughly. However, I'm told I can spin up another Amazon virtual machine for under
1c per hour. XACML expertise is in limited supply and several orders of magnitude more
expensive. Thus I strive to make XACML easier to use, rather than more efficient to
process, because that makes more sense economically.

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

Not in the ViewDS PAP.

On the other hand, a more general OA rule that didn't depend on the day at all,
or only distinguished between work days and weekends, wouldn't need to be changed.

> The latter leads to performance
> issues by repeating the same computations twice.

Not my first priority and not really an issue for me.

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

Indeed.

If I were thinking ahead to XACML 4.0, then I would consider adding conditions
to obligations and advice so that the OA policies could be merged with regular
policies. But, I can solve the problems with obligations using the XACML 3.0
core, which is good enough for right now.

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

But not necessarily in perfect alignment, and not necessarily managed by the
same people where delegation is involved.

> 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 want to send an alert to user Bob whenever someone modifies File X, but not when
someone only reads File X. Suppose that user Alice is allowed to read and modify
File X. I might write a rule that said (Permit if subject-id=Alice and
resource-id=File X and (action=read or action=modify)). However, if I attach my
alert Bob obligation to this rule, then the obligation will be sent to the PEP if
Alice only reads File X. To avoid that I have to create two rules, one that says
(Permit if subject-id=Alice and resource-id=File X and action=read) and has no
obligation and one that says (Permit if subject-id=Alice and resource-id=File X
and action=modify) and carries the alert Bob obligation.

Regards,
Steven

> 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