OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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)



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
> ...


David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]