Re: [xacml] Obligation Proposal

[Erik Rissanen <erik@axiomatics.com>]

Hal Lockhart wrote:
> I like the proposal for Obligation Families. I am not sure I completely
> understand it though.
>   

I'm happy to hear that. That you like it, that is. Not that you don't 
understand in completely. ;-)

> It is my understanding that a family represents a particular combination
> of combining behaviors is that correct?
>   

Yes. A family is similar to a parameterized policy combining algorithm, 
except that it works on obligations rather than Permit/Deny. Each family 
has options/attribute/parameters/whatever-you-call-it which are 
compatible. For instance, choosing only the highest priority obligation 
into the final result does not make sense with ordered enforcement, so 
these go into separate families.

> I think any given Obligation has to be a member of exactly one family,
> correct?
>   

Yes. I think the draft should already say this.

>   
>> There are a number of open questions still remaining. Two that come to
>>     
> mind >now are:
>
>   
>> 1. How are families in turn related to each other?
>>     
>
> I am not sure I understand the question. It seems to me that combining
> has to occur within each family. The results of combining each family
> are aggregated. In other words Families are Repetitive with respect to
> each other.
>   

It is exactly the nature of this aggregation I am referring to. It is 
not entirely obvious that the results from the families should simply by 
aggregated as a union into a single set. It is conceivable that other 
forms of combination could happen at this level. Bill was looking into 
this in the early generalized decision work I think, but it turned out 
to be quite complex.

My proposal is that we simply aggregate for now. It's simple and should 
be fine for most uses. If more is needed later, we can do that then.

>> 2. I didn't use URI for identifying the family types. The type is clear
>>     
> from the xsi:type xml attribute, but using names for identifiers is not
> used much in XACML, so I am not sure if people like that. :)
>
> I prefer consistency, but I don't feel too strongly. What would it look
> like with a URI?
>   

I can make an example of that, but I don't have the time right away now.

>> And, as I wrote earlier, the use cases get more complex with
>>     
> delegation.
>
> I had forgotten we agreed to carry obligations in Admin policies which
> are applied to the access decision. Do we have motivating use cases for
> this functionality? I am not really sure how it would be used. I agree
> that things will get quite complex.
>   

The use case I am thinking about here, when I say it gets more complex, 
is the access override/log level use case I have used a lot here. It 
goes like this:

There are two kinds of obligations, which refer to two levels of logging 
requirements. Normal logging and extra logging with user confirmation.

In case of a normal logging obligations, the PEP makes a normal audit 
log entry.

In case of the extra logging with user confirmation the PEP asks the 
user for confirmation before proceeding and then makes a special note in 
the audit log about this use.

The use of the extra confirmation is for special emergency permissions, 
for instance in a hospital. In a hospital the security policy may allow 
access in case of an emergency, even if there is no normal access 
permission. A computer cannot determinate when an emergency has actually 
occurred, so we cannot really write machine enforceable rules for 
emergency permissions.  One way to implement this in XACML would be to 
write a policy which allows a very wide range of accesses, but it is 
marked with the extra logging obligation. Any such logs will be audited 
carefully to prevent abuse of emergency access permissions. The fact 
that the audit logs are separate makes it possible to do this audit 
efficiently since we can devote the resources to the suspicious cases 
rather than the thousands/millions of everyday accesses.

So far this use case is handled by the new obligation profile draft. We 
simply give priority to the normal logging obligation so the wide access 
permission does not apply until there is not a more specific regular 
permission.

However what is not handled is delegation of an emergency permission. We 
would like the case to be that if someone has the right to delegate an 
emergency permission, then he should not be able to delegate a regular 
permission. This means combination of obligations in delegation should 
happen the other way around from above: emergency logging takes 
precedence over regular logging.

This would mean that the model has to differentiate between different 
forms of combination: one for access permissions and one for delegation 
chains.

My opinion for this is: This use case is not important enough to warrant 
the extra complexity.

Regarding obligations in admin policies in general, the motivation to 
collect the obligations into the access result was that this way it is 
possible for an administrator to require an obligation for any access 
which is granted based on his policy. For instance: "all accesses based 
on this delegation policy have to be encrypted."

Best regards,
Erik