[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] XACML Obligations - a concurrency model
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 > > ... > -- ***************************************************************** 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]