Difference between Obligations and Conditions

[Rebekah Lepro <rlepro@arc.nasa.gov>]

Colleagues -

There has been a debate for days on the OGSA-Authorization mailing list
regarding the differences in semantics between a Condition and an
Obligation.  Establishing the semantic differences the intent of SAML
Conditions and XACML Obligations in the realm of deciding and enforcing
authorization decisions is an important point of agreement to reach.

I wanted to ask for your opinions and insight as to the differences between
a condition and an obligation to add to the discussion mix.   I've included
much of the original thread from the OGSA-AuthZ list below to frame the
request.

Thoughts?

Rebekah





I'm still not seeing a substantial difference here between a Condition and
an Obligation.

It seems that if I encode something as either an Obligation or a Condition,
it must be satisfied or the authorization fails. Can someone provide me a
statement that describes a semantic difference in behavior?

David's definitions define the difference as whether or not a third party is
involved in satisfying the Condition or Obligation. I don't see that as a
meaningful difference. That sounds important only internally to the PEP.
Some PEPs may need help of a third party (and maybe a fourth...) others may
not. This would mean as a policy writing I have to know if the PEP is going
to need help satisfying my Condition and if so encode it as an Obligation?

David's definitions:

> If the returned blob requires the PEP to evaluate something (internally)
> before enforcing the decision, then it is a condition (as in this case).
> Constraints are conditions that need to be evaluated
> 
> If the returned blob requires the PEP to undertake some action (with an
> external object) before it enforces the decision, then it is an obligation
> 

Von

David Chadwick writes (14:50 January 10, 2004): Frank

> Using the two pdp/pep model that you describe below, the first (Xacml) pdp
> would return an obligation to the first pep, for it to inform the second pep
> about the sensistivity label. The first pep would perform its obligation then
> grant the user access to the second pep. The second pdp would grant or deny
> access based on the data item being accessed and no conditions would need to
> be returned. This scheme fits in with my understanding of obligations. Von's
> initial description only had a single Pep/PDP, so in this case it was a
> condition that was returned by the PDP and not an obligation, because no other
> party was involved in the PEP enforcing the decision.
> 
> regards
> 
> David
> 
> 
> Frank Siebenlist wrote:
> 
>> Just to make sure that my last remark is understood correctly, imagine a
>> realistic implementation of this scheme where sensitivity labels are used in
>> database queries to enforce (part of the) policy, and that the association of
>> those labels with the subject's clearance levelsis stored in an xacml
>> policy-db, and somehow comunicated through these obligations.
>> 
>> There are in fact two policy decision/enforcement points: one xacml-pdp/pep
>> and a rdbms-pdp/pep.
>> 
>> Suppose the xacml-pdp returns a permit decision with a true "obligation" in
>> your semantics, to set a local variable with the sensitivity label info.
>> That's all this xacml-pep does, it doesn't interpret that variable data,
>> doesn't evaluate anything, and doesn't even know what it means. So, the
>> "external action" of this pep is the setting of this state variable
>> (conceptually the equivalent of sending an email).
>> 
>> However, as a desirable side-effect, the value/state of this local variable
>> is somehow communicated to the next component which makes the db-queries
>> (e.g. environment-variables/per-thread-data), and added as a policy
>> "condition" through an added where-clause, such that the rdbms-pdp/pep does
>> the right thing.
>> 
>> -Frank.
>> 
>> PS. For me this semantic horse is dead...
>> 
>> Frank Siebenlist wrote:
>> 
>>> double ough - let's try again: ... so the only way to communicate your
>>> condition in an xacml decision is through an xacml obligation ;-)
>>> 
>>> -FS.
>>> 
>>> 
>>> Frank Siebenlist wrote:
>>> 
>>>> Ough ... so the only way to communicate your condition in an xacml decision
>>>> is through an xacml condition ;-)
>>>> 
>>>> -FS.
>>>> 
>>>> D.W.Chadwick wrote:
>>>> 
>>>>> Frank
>>>>> 
>>>>> right as you usually are, in this case I dont think you are.  It sounds
>>>>> much more like a condition to me.
>>>>> 
>>>>> I like to think of the difference between obligations and conditions as
>>>>> the following
>>>>> 
>>>>> If the returned blob requires the PEP to evaluate something (internally)
>>>>> before enforcing the decision, then it is a condition (as in this case).
>>>>> Constraints are conditions that need to be evaluated
>>>>> 
>>>>> If the returned blob requires the PEP to undertake some action (with an
>>>>> external object) before it enforces the decision, then it is an obligation
>>>>> 
>>>>> Ultimately of course everything could be reduced to an obligation, since
>>>>> you have to perform an action when you evaluate a condition (the action is
>>>>> evaluate) but not with an external object, so another way to think of the
>>>>> difference is that a condition is a special type of obligation that is
>>>>> performed internally by the PEP, whereas an obligation is performed
>>>>> externally. This is why enforcing a time constraint is really a condition
>>>>> rather than an obligation.
>>>>> 
>>>>> 
>>>>> here is the Ponder definition
>>>>> 
>>>>> Obligations are activities subjects (human or automated manager
>>>>> components) must perform on objects in the target domain. <Note that there
>>>>> are subjects and objects> Obligation policies thus define the conditions
>>>>> for performing a wide range of management actions such as change Quality
>>>>> of Service, when to perform storage server backups, register new users in
>>>>> a system, or install new software.
>>>>> 
>>>>> 
>>>>> David
>>>>> 
>>>>> 
>>>>> 
>>>>> Frank Siebenlist wrote:
>>>>> 
>>>>>> As happens once in a while, I believe Von is right on target with his
>>>>>> example. (I believe it used to be part of his job description at UC/ANL
>>>>>> to set me straight - maybe NCSA has copied that part ;-)
>>>>>> 
>>>>>> Tagging data with sensitivity labels is done for many good and bad
>>>>>> reasons, of which one is performance.
>>>>>> 
>>>>>> When you have to make a separate external access control decision on
>>>>>> every single row that that is returned from a select * sql-query, the
>>>>>> retrieval will be orders of magnitude slower than adding a filter for a
>>>>>> sensitivity label in a sql-where clause - and that is when you co-locate
>>>>>> the database engine and the PDP: if you're incurring an invocation over
>>>>>> the network for each decision query you may want to go out for a cup of
>>>>>> coffee (in the corporate world you would make such a mistake only
>>>>>> once...).
>>>>>> 
>>>>>> In other words, there are situations where the policy decision has to be
>>>>>> split in two: first get the sensitivity labels that apply to the subject,
>>>>>> then use those in the "natural" context of where the labels are present.
>>>>>> 
>>>>>> By returning a sensitivity label as obligation data, one essentially
>>>>>> communicates the policy decision that a certain subject is allowed to
>>>>>> invoke the requested action on the resource if and only if the PEP
>>>>>> enforces the contraint that the sensitivity label has a certain value,
>>>>>> which sounds very much in the spirit of "obligation".
>>>>>> 
>>>>>> The sensitivity label values can be application dependent and their use
>>>>>> will also be very application dependent. You could even imagine returning
>>>>>> the regular expression to use in your grep/find command to filter out
>>>>>> only those files/lines/records that can be viewed by the subject.
>>>>>> 
>>>>>> Regards, Frank.
>>>>>> 
>>>>>> O.Otenko wrote:
>>>>>> 
>>>>>>> Von Welch wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> ...A requestor sends a request to a Database service asking for all
>>>>>>>> records (select *).
>>>>>>>> 
>>>>>>>> The DB sends a request to for a access control decision to the PDP (Can
>>>>>>>> Subject Von perform Action "select *" on Target SomeDB).
>>>>>>>> 
>>>>>>>> The PDP replies PERMIT with Obligation that Action be "select * where
>>>>>>>> owner = Von or clearance = public" Basically the response from the PDP
>>>>>>>> needs to impose some form of transformation on the action and that neds
>>>>>>>> to be returned to the PEP somehow in a form that the PEP must either
>>>>>>>> perform or deny the request.
>>>>>>>> 
>>>>>>>> Von
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> In my opinion this is not the policy issue. Look, this is similar to the
>>>>>>> following: a user types "grep *" in Linux. The policy decision could be
>>>>>>> to find out whether the user is allowed to read ALL files.
>>>>>>> Alternatively, which is the real case, grep will issue a sequence of
>>>>>>> access requests for each particular file it can find, so the policy
>>>>>>> decision will be about whether the user is allowed to read the contents
>>>>>>> of the directory (can grep look for files), and then about each
>>>>>>> particular file grep finds.
>>>>>>> 
>>>>>>> However, it is not the policy decision to find out whether the user is
>>>>>>> allowed to read all the contents of the files, or rather the request has
>>>>>>> to be modified, say, to "grep "^#" *" - to allow see only the lines
>>>>>>> containing "#" at the beginning.
>>>>>>> 
>>>>>>> In other words, the policy may put constraints on Security attributes
>>>>>>> the targets must have, but the policy cannot enforce conditions on
>>>>>>> arbitrary attributes of the targets - it will become way too complicated
>>>>>>> to specify the meaning of those attributes and how they should be
>>>>>>> obtained form the target, plus the meaning of the operation itself!
>>>>>>> 
>>>>>>> 
>>>>>>> Therefore, in my opinion, "select *" should not be altered. It should
>>>>>>> either be treated as "can the user read ANY record?" (no, because the
>>>>>>> user cannot read SOME records), or the PEP (or someone else) should
>>>>>>> split the request into a chain of requests to obtain each individual
>>>>>>> record, and then the policy decision will tell whether that particular
>>>>>>> record is accessible for the user.
>>>>>>> 
>>>>>>> Consider that to modify the request to enforce the rule you are talking
>>>>>>> about, the PDP would need to understand how to split the request into
>>>>>>> the chain of requests, figure out the rule that unifies the allowed
>>>>>>> requests, and then find out how the request should be modified to get
>>>>>>> the same output.
>>>>>>> 
>>>>>>> e.g. sassa says: "select * where owner=Von" PDP modifies: "select *
>>>>>>> where owner=Von where owner=Sassa" - nonsense! The PDP would have to be
>>>>>>> more clever than that!
>>>>>>> 
>>>>>>> So the PDP needs to understand What the action will do, which will
>>>>>>> require application-specific interpretation. I think loading operation
>>>>>>> semantics into the policy will be too complex for an
>>>>>>> application-INDEPENDENT decision-making module.
>>>>>>> 
>>>>>>> You can introduce obligations of that kind, but who is going to
>>>>>>> _implement_ granularity of access control so fine?
>>>>>>> 
>>>>>>> 
>>>>>>> Sassa
>>>>>>> 
>>>>>>>