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

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

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

...