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