Re: [xacml-comment] XACML Obligations - a concurrency model

[Oleksandr Otenko <oleksandr.otenko@oracle.com>]

This is an artificial example with artificial assumptions (e.g. one user 
runs one process at a time). Anyway, the system will be more available, 
if the amount is withdrawn tentatively, the account is 
unblocked=available for concurrent use right after that, and the 
usability of the system is not affected by the speed at which each 
process completes. In this case you would need guarantees that the 
amount will be credited back, if money dispensing fails for whatever reason.

As I said, this is an artificial example, just to illustrate that the 
Obligation vs Decision coherence must be carefully balanced, as 
straightforward solutions may not always offer the best value.


Alex

David Chadwick wrote:
> Agreed.
>
> The With obligations will lock up the coordination/obligation 
> attributes that they read. So it depends upon the granularity of the 
> locking mechanism as to whether other actions are locked out from 
> decision making or not. If in the ATM example, locking is done on a 
> per user account basis, then only the same user is locked out of 
> making parallel withdrawals from 2 or more ATM machines at the same 
> time, which is actually a good thing :-) But no other user withdrawals 
> are stopped since their coordination attributes have not been locked. 
> (This is what we actually implemented)
>
> regards
>
> David
>
>
> Oleksandr Otenko wrote:
>> David Chadwick wrote:
>> ...
>>>>     * "state information (...) is recorded in an external 
>>>> "coordination"
>>>>       database and
>>>>     * picked up by a PIP,
>>>>     * sent to the PDP,
>>>>     * then updated via obligations"
>>>>
>>>> I assume that there must be some additional context here, because 
>>>> as stated this appears that for some reason a PIP getting data from 
>>>> an external database that has just been updated and is sending 
>>>> unsolicited data to the PDP, which then for some reason generates 
>>>> Obligaions which somehow result in the information being updated.
>>>
>>> It not magic. In fact the the obligation handler and the PIP are 
>>> written as a pair that go together. the PIP reads the data and the 
>>> obligation writes new values of the data. The PIP locks the data and 
>>> the obligation service unlocks the data.
>>>
>>> the main issue then is, how does the PIP know which data to fetch, 
>>> since it is written into the obligation of the policy by the policy 
>>> writer (so the obligation handler has no problem in deciding what it 
>>> needs to update). In our implementation we added a call to the PDP 
>>> "getAttributes" which returned the environment attributes that 
>>> needed to be fetched for authz decisions, and this was how the PIP 
>>> knew what to read. But this is not efficient for large policies with 
>>> lots of different attributes. So the XACML method of returning 
>>> attributes in Authz decision responses can also be used to tell the 
>>> PIP what it needs to pick up. We can also pass the database 
>>> transaction ID to the obligation handler by the PIP inserting this 
>>> as an environment attribute in the request context which is passed 
>>> to the PDP (and ignored) and then onto the obligation service (and 
>>> used).
>> This is one implementation of what's missing from XACML spec. Not 
>> everyone needs the same coherency of Obligations and Decisions, as 
>> this is achieved at the expense of availability. In David's example 
>> the system will be rendered completely unavailable until the values 
>> are unlocked. This isn't a small problem, because the success of the 
>> Decision enforcement may depend on the ability to deliver the 
>> response to the client. You wouldn't want your account locked just 
>> because one ATM got jammed by your card, or because this particular 
>> Grid Job is taking 2 days to complete (and for the Obligation 
>> Enforcer to know if it succeeded).
>>
>>
>>
>> Alex
>>
>> ...
>>
>