[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] XACML Obligations - a concurrency model
Hi Rich Rich.Levinson wrote: > Hi David, > > Thanks for the feedback. I think it is important that we understand the > use cases that drive new feature requirements, so that the appropriate > mechanisms can be incorporated to the spec. > > I guess that I have been using a philosophy along the lines of the PDP > makes the decision and returns the result to the PEP and it is up to the > PEP to take whatever subsequent actions are required to ensure that the > decision is properly enforced. This is exactly my model as well. In the cases you describe I am not sure I > fully understand the details well enough yet to have a good sense of how > they fit the Obligation model, whether it be the existing 2.0 model or > an enhanced 3.0+ model. Actually your description to Alexander was pretty much in line with the model I have as well. > > That being said, I will try to respond to your comments. > > It sounds like the first comment with the suggested Chronicle attribute > for an Obligation has been decided although maybe not in the most > desirable manner. I assume we are not discussing that here. > > I am trying to understand the "first" use case: global daily withdrawal > limit. I just responded to what may be a similar case presented by > Oleksandr here: It is virtually the same use case. > http://lists.oasis-open.org/archives/xacml-comment/200811/msg00010.html > so, first let's see what is different if anything. You say > > * "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). > Let me try to be pro-active and assume this is in the context of an ATM > withdrawal where > > * the user is executing a withdrawal transaction on their account, > * the appl then requests the PDP for authorization, > * at which point the PDP "calls out" thru context handler to PIP > which maintains global data and obtains the current daily limit > balance, > * tests the balance against the amount requested to be withdrawn > * and, for example, returns a Permit with possibly two Obligation > Attributes: one for the global balance and one for the amount > withdrawn. > * presumably, then, if the user actually goes ahead and completes > the transaction, the global balance will need to be updated at > that point. > > If this is correct, it does sound a lot like the scenario I described in > my response to Oleksandr, where I was suggesting that the transaction > coordinator really needed to be some entity other than the PDP, because > the PDP effectively just performs a service midway in the transaction > and is neither in a position to start or end a transaction, and > presumably all Attributes it processes would need to be handled within > the context of a transaction. Comments? We use the context handler to do all this, so that the PDP remains a stateless PDP that simply makes decisions and nothing else. > > On the 2nd one, "break the glass", I need a little more context: > > * presumably, "break the glass" is some kind of operation that the > user requests access to, correct. It is at this point that the alarm is rung (whatever obligation you want that to be) and that the state variable "glass broken" is set to true. and if granted the user then carries > around this special attribute that can be used to override certain > types of operations It is not really a user attribute, since the user could then manipulate it. It is a state variable set by the system. We actually use our coordination service to set this variable, as in the ATM case above (so in general one can regard the coordination database as a series of state tables, and there are policy statements that make decisions based on certain states.) (i.e. I assume if you "break the glass" that > that does not give you permission to "rob the bank" :) ). Of course not. There is a policy statement saying who is allowed to BTG for which resources (BTG is an action in this case), and there are other policy statements saying which resources can be accessed when the glass broken state is true. On > return with Permit an Obligation causes manager to be notified of > situation, and presumably triggers some "higher level of audit > trail" (audit by PDP?, PEP?, both?, other?; presumably application > and PDP specific?) this is the alarm ringing set of obligations, that are application specific. They can essentially be anything that will cause humans to do an after the event audit. The assumption we have is that all policies will contain flaws (they were written by humans after all) and BTG allows humans to make dynamic decisions about whether the policy is correct or not, and BTG if the polic is wrong, knowing that they will have to face the consequences later. The policy writer decides which policy rules can be overridden with BTG (such as any GP can see patient record if glass is broken) and which cannot (such as withdraw a million pounds) > * on subsequent authorization requests, I assume the user submits > this special attribute with the request, the system submits it on the user's behalf. the user is not aware of this state variable, only that he can BTG and then get access. which, when used to allow > the user access, causes an obligation to be returned along with > the decision, which directs the PEP (or whatever) to carry out the > "higher level of audit". correct > > Based on those assumptions, I don't see the reqt for any special > obligation, however, I may be using incorrect or incomplete assumptions. The requirement is that some obligations must be carried out before the user's action, others along with the user's action, and others afterwards (and these can fail), which is why we need Before With and After. But we have no requirements for "any time" obligations which Alex has already pointed out is the same as After (which I agree with). > > In any event, those are my initial reactions. I will not be able to > respond further for a couple of weeks, however, I encourage you to > pursue the discussion with whomever on the list wishes to participate. > (Note: I am also cc'ing the main xacml list, which will have to be done > by others for subsequent exchanges.) I have now joined the list so that no more cc'ing is required regards David > > Thanks, > Rich > > David Chadwick wrote: >> Hi Rich >> >> we are working on implementing obligations now, as part of the EC TAS3 >> project (to which Oracle is actually a partner, but Oracle is >> primarily working on the legal issues of privacy rather than PDP >> development. The PEP/PDP work is being led by myself). >> >> The idea of before, after, and with obligations was raised by myself >> on the XACML users list in May 2007. We originally proposed a >> Chronicle attribute for the obligation element, and wrote this into an >> Open Grid Forum draft that I was editing. But discussions on the XACML >> list revealed that the XACML group were not ready to do >> standardisation of the temporal aspects of obligation at that time, >> and it was recommended that we provisionally use different URIs to >> indicate the same obligation with different temporal aspects to it. It >> does mean potentially having three URIs for the same obligation, but >> we changed our OGF spec and implementation to do this. >> >> We have a number of use cases where we are using obligations. The >> first is coordinated decision making where state information >> (retainedADI in ISO 10181-3 parlance) is recorded in an external >> "coordination" database and picked up by a PIP, sent to the PDP, then >> updated via obligations. We implemented a multi PDP system to simulate >> the taking of money from ATM machines around the globe and users >> having a global daily withdrawal limit. The second is Break the Glass >> policies where someone who does not have access is granted access if >> they first break the glass. We use obligations to notify the manager >> that the glass has been broken and to switch on a higher level of >> audit trails. (BTW, all this will be released as open source software >> to the community - the coordination software is already available from >> our web site). >> >> Some of the obligations need to be implemented before the user's >> action is performed (e.g.BTG), and some after (e.g.ATM example). I >> dont believe that your two cases below cover all use cases e.g. switch >> logging to a higher level. >> >> I suspect this message will get bounced by the xacml list if it is >> subscription only, in which case could you forward it for me >> >> regards >> >> David >> >> >> Rich.Levinson wrote: >>> Hello Erik and Oleksandr, >>> >>> I would like to throw 2 cents in here, as well. As Erik states, we >>> have not been actively reviewing this spec since it is not planned as >>> part of the core release of 3.0. The issue caught my attention, >>> because I hadn't realized this stateful type of info had been added >>> to Obligations WD3: >>> http://www.oasis-open.org/committees/download.php/27230/xacml-3.0-obligation-v1-wd-03.zip >>> >>> which, it might be useful to note, was actually released on >>> 20-Feb-08, as opposed to the date in the spec which was not updated >>> and is the same as WD2, which is 28-Dec-07. >>> >>> In any event, I had done some thinking about Obligations earlier wrt >>> to XACML 2.0 and my sense was that it would make sense to think of 2 >>> classes of Obligations: >>> >>> 1. pre-Condition Obligations, which need to be in effect before >>> access is granted, for example, the subject guarantees not to >>> disclose the data being requested to 3rd parties. >>> 2. post-Condition Obligations, which generally will take effect after >>> access is granted, for example, the subject guarantees to delete >>> the data after 30 days, although, this may also be viewed as a >>> pre-Condition Obligation; possibly a better example would be that >>> the PEP will send an email to the party about whom the data being >>> returned is about. >>> >>> Using 2.0, the way I would probably go about implementing case 1, the >>> pre-condition, would be to issue a Deny with an accompanying >>> Obligation which the PEP could inform the user that in order to >>> access the data, that the user would have to agree to some >>> conditions, which the PEP could obtain, and then the PEP would >>> re-submit the request with an additional Attribute indicating that >>> this Obligation had been met before the request was being made. >>> >>> With this approach, I see little need to introduce the potential >>> complexity that the WD3 proposal includes with the "before, after, >>> with, any" constructs, which as the previous emails indicate are not >>> particularly clearly definable without probably the necessity of >>> introducing some kind of workflow at the PEP which will guarantee >>> ordering of tasks or require some kind of 2-phase commit to ensure >>> that Obligations and access decisions are not in violation of some >>> yet to be defined rules for some yet to be defined use cases. >>> >>> If there are such use cases, I think it would be advisable to >>> introduce them as a basis for requiring these capabilities, before we >>> consume a number of cycles analyzing the technology. >>> >>> Thanks, >>> Rich >>> >>> >>> >>> Oleksandr Otenko wrote: >>>> Thanks for your response. >>>> >>>> I notice there are obligations such as Attribute Assignment. I >>>> regard it is possible to use the values of the attributes during >>>> concurrent decision processes, therefore it is important to >>>> understand the concurrency model. >>>> >>>> BTW, as far as I am aware, the ATMs first withdraw the money, then >>>> dispense, and only if the dispense phase fails, they execute a >>>> recovery or rollback step. There is no guarantee when the rollback >>>> step completes, and in some implementations you can see the account >>>> debited for significant periods of time. Account update will be a >>>> common case of obligation, and often it will be important to lock >>>> some amount even upon failure than overspend. >>>> >>>> >>>> Alex >>>> >>>> Erik Rissanen wrote: >>>>> Hi, >>>>> >>>>> Thanks for the very thorough analysis. >>>>> >>>>> You can find the draft under "work in progress" on the XACML TC web >>>>> page. It's called "obligation families". >>>>> >>>>> The draft is very early work, carelessly written by me :-), and >>>>> certainly not in any way ready for implementation. Just so >>>>> everybody knows... :-) >>>>> >>>>> I have not read your analysis very carefully yet, but I get the >>>>> feeling that there has been a misunderstanding. The words "after", >>>>> "before" and "with" are confusing. The draft does not attempt to >>>>> define a temporal/causal order of enforcement. There was no >>>>> intention to provide any guarantees with respect to side effects of >>>>> enforcement. >>>>> >>>>> I used those names because I couldn't think of anything better and >>>>> because after and before are simple ways to implement the >>>>> guarantees which I was describing. >>>>> >>>>> What really was intended was to provide a mechanism which allows >>>>> policy writers to have guarantees about the atomicity of the dual >>>>> enforcement of the obligation and the access enforcement. To say >>>>> things like "access must not be granted if obligations cannot be >>>>> enforced", or "an obligation must not be enforced unless access >>>>> enforcement is guaranteed to succeed", etc. >>>>> >>>>> BTW, you are right, a simple method by which to implement the >>>>> "After" guarantee is simply to never run the obligation. That is >>>>> the intended meaning. It is intended for those cases where it is >>>>> important that the obligation is _never_ enforced unless the access >>>>> was successfully enforced. For instance, consider a case where a >>>>> granted access means a billing event. If you are concerned about >>>>> your customer relations you want to make sure that you never bill >>>>> for an access which was not successful. >>>>> >>>>> You should also note that in many cases some of these guarantees >>>>> cannot be provided. If the guarantee cannot be provided the PEP >>>>> should report failure. It might also be possible to detect this >>>>> already at the time of policy deployment and the PDP could return >>>>> an error saying that the policy contains requirements which cannot >>>>> be enforced. >>>>> >>>>> In any case, I am not pursuing this right now because I am focusing >>>>> on getting the XACML 3.0 core done. I will look into this in detail >>>>> once the core XACML stuff is done, and we revisit this work. >>>>> >>>>> Best regards, >>>>> Erik >>>>> Oleksandr Otenko wrote: >>>>>> Hi, >>>>>> >>>>>> We were discussing XACML draft with David with regards to the >>>>>> Obligations definitions. Can you help me understand the reasoning >>>>>> behind them? I cannot find the draft myself, but I have issues >>>>>> with what David quoted; I trust it is a complete copy: >>>>>> >>>>>>> *Obligation before access* >>>>>>> This mode guarantees that if the access control decision is >>>>>>> successfully enforced, then the obligation is also successfully >>>>>>> enforced. (This mode does NOT guarantee that access decision is >>>>>>> successfully enforced even if the obligation is enforced.) >>>>>>> >>>>>>> *Obligation after access* >>>>>>> This mode guarantees that if the obligation is successfully >>>>>>> enforced, then the access control decision is also successfully >>>>>>> enforced. (This mode does NOT guarantee that the obligation is >>>>>>> successfully enforced even if the access decision is enforced.) >>>>>>> >>>>>>> *Obligation with access* >>>>>>> This mode guarantees that the obligation is successfully enforced >>>>>>> if and only if the access control decision is successfully enforced. >>>>>>> *Any timing* >>>>>>> In this mode the PEP makes a best effort attempt to enforce both >>>>>>> the obligation and the access decision and no guarantee is made >>>>>>> about success. >>>>>> >>>>>> >>>>>> I have no problem with the definitions as they are, but want to >>>>>> clarify >>>>>> it means that: >>>>>> >>>>>> * *With* is the same as *After* in this interpretation >>>>>> * *Any timing* can be the same as *After* >>>>>> * *After* is not obligatory for enforcement >>>>>> * (Thus only *Before* is a true obligation) >>>>>> >>>>>> This becomes evident if you consider a concurrency model with >>>>>> *happens-before* predicate (e.g. as used in Java memory model, 3-rd >>>>>> edition). Please, follow me on this: >>>>>> >>>>>> Since *After* starts after the access decision is enforced, there >>>>>> is no >>>>>> guarantee when the effects of the obligation are observed. This is >>>>>> fine >>>>>> with me, as this is the definition of the "best effort", and there is >>>>>> the place for that in the security policies. However, the cheapest >>>>>> way >>>>>> to implement "best effort" is to /never/ execute such obligation. >>>>>> This >>>>>> is made clear in the statement about *After*, but: a) this is just >>>>>> like >>>>>> *Any timing*, so the latter can be deprecated; b) marking obligation >>>>>> *After* makes it not obligatory for enforcement (kind of, it >>>>>> becomes a >>>>>> non-Obligation). >>>>>> >>>>>> The definition of *With* in the form quoted also lacks the >>>>>> definition of >>>>>> the timing the effects of *With* are observed. All that it states, is >>>>>> that it can be observed after a successful access control decision >>>>>> enforcement: it doesn't state /how soon/. This allows for an >>>>>> implementation that performs the "best effort" enforcement. This >>>>>> also is >>>>>> fine with me, but then *With* becomes the same as *After*. >>>>>> >>>>>> Please, correct me, but it seems the definition of the obligations in >>>>>> the current form can be rewritten using the *happens-before* >>>>>> predicate >>>>>> as follows: >>>>>> >>>>>> * The last step of *Before* Obligation *happens-before* the first >>>>>> step of access control decision enforcement process >>>>>> * The last step of the access control decision enforcement process >>>>>> *happens-before* the /first/ step of *After* Obligation >>>>>> * The last step of the access control decision enforcement process >>>>>> *happens-before* the /last/ step of *With* Obligation >>>>>> * *Any timing* has no *happens-before* relationship with access >>>>>> control decision enforcement process (unsynchronized; hmmmm, >>>>>> maybe >>>>>> there is some value in having it, after all) >>>>>> >>>>>> You can see why I think *With* is the same as *After*: *After*'s >>>>>> /last/ >>>>>> step is executed in the same way as *With*'s, and since there is no >>>>>> requirement about the timing of the /first/ step of *With*, the least >>>>>> effort implementation is to implement it as *After*. >>>>>> >>>>>> I propose to modify the definition of *With* using the >>>>>> *happens-before* >>>>>> predicate, which allows to express the timing of the enforcement more >>>>>> precisely, and makes the purpose of the obligations more clear: >>>>>> >>>>>> * The last step of *Before* Obligation *happens-before* the first >>>>>> step of access control decision enforcement process >>>>>> o This makes sure the effects of the Obligation can be >>>>>> observed /during the access control decision enforcement >>>>>> process/ >>>>>> o *Caveat*: the effects of the Obligation may not be >>>>>> observed, >>>>>> if there was an intervening Obligation enforced >>>>>> concurrently >>>>>> * The last step of the access control decision enforcement process >>>>>> *happens-before* the first step of *After* Obligation >>>>>> o This makes sure the effects of the access control decision >>>>>> enforcement process can be observed /during the Obligation >>>>>> enforcement/ >>>>>> o *Caveat*: the effects of the decision enforcement may >>>>>> not be >>>>>> observed, if there was an intervening decision enforced >>>>>> concurrently >>>>>> * The last step of *With* Obligation *happens-before* the last >>>>>> step >>>>>> of the access control decision enforcement process >>>>>> o There is no guarantee that either of the processes will >>>>>> observe the effects of the other >>>>>> o This makes sure the effects of the Obligation can be >>>>>> observed at the same time the effects of the access >>>>>> control >>>>>> decision enforcement are >>>>>> o *Caveat*: the effects of the Obligation may not be >>>>>> observed, >>>>>> if there was an intervening Obligation enforced >>>>>> concurrently >>>>>> o *Caveat*: this does not explain what happens to the >>>>>> Obligation, if the access control decision is /not >>>>>> enforced/ >>>>>> (e.g. fails) >>>>>> >>>>>> If it is critical to observe all effects (reads: it is critical to >>>>>> beat >>>>>> all caveats), use the synchronization techniques between the monitor, >>>>>> the Obligation enforcer, and the decision enforcer. >>>>>> >>>>>> Notice that now *With* can be implemented as *Before*, but that is >>>>>> good >>>>>> as far as the word Obligation is concerned. There is a significant >>>>>> difference in the wording of the two, which allows the >>>>>> implementers to >>>>>> optimize *With* differently to *Before*. >>>>>> >>>>>> >>>>>> *Discussion of With Obligation* >>>>>> >>>>>> Access control decision enforcement and Obligation enforcement are >>>>>> independent processes. This means that without explicit >>>>>> synchronization >>>>>> the effects of the processes can be observed in an arbitrary >>>>>> order. The >>>>>> existing wording of the draft allows for the effects of *With* to >>>>>> not be >>>>>> observed at all. My concern is that it will be implemented as >>>>>> such, and >>>>>> the only Obligation mandatory for enforcement is *Before*. The >>>>>> modification I propose is necessary, because there is no way to >>>>>> /guarantee/ when the process /ends/. >>>>>> >>>>>> The modified definitions are based on a concurrency model, and they >>>>>> clearly state the observed effects of each Obligation in a >>>>>> concurrent world. >>>>>> >>>>>> In my opinion it is not possible to implement the "if and only if" >>>>>> part >>>>>> of the *With* Obligation without a concurrency issue. This is because >>>>>> either it is enforced *After* the access control decision >>>>>> enforcement is >>>>>> known to have succeeded (no point to have *With* as a separate >>>>>> type), or >>>>>> allow the Obligation's effects to be observed upon access control >>>>>> decision enforcement failure. My proposal is to allow the latter, >>>>>> as in >>>>>> that case it makes sense to have *With* as a separate type of the >>>>>> Obligation. >>>>>> >>>>>> It is possible to reduce the implementation options by placing >>>>>> further >>>>>> constraints, e.g.: >>>>>> >>>>>> * The first step of the access control decision enforcement >>>>>> *happens-before* the first step of *With* Obligation >>>>>> o This makes sure that the implementation is not the same as >>>>>> that of *Before* >>>>>> o The only reason you may observe the effects of this >>>>>> Obligation is that the decision enforcement was >>>>>> /attempted/ >>>>>> * The effects of the *With* Obligation should not be observed, if >>>>>> the first step of the *With* Obligation *happens-before* the >>>>>> access control decision enforcement failure >>>>>> o This is a lenient implementation of the "if and only if" >>>>>> requirement of the *With* Obligation >>>>>> o There is a possibility that the effect of the *With* >>>>>> Obligation is observed for indefinite time, at least if >>>>>> its >>>>>> last step /also/ *happened-before* the failure to enforce >>>>>> the access control decision >>>>>> o There is a point for the implementors to spend the effort >>>>>> rolling the Obligation's effects back upon the failure of >>>>>> decision enforcement, to create a /fairer/ system of >>>>>> obligations; but if that is critical, a new constraint >>>>>> needs >>>>>> to be introduced to clarify before when the last step >>>>>> of the >>>>>> rollback should happen >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dr. Alex Otenko >>>>>> >>>>>> >>>>> >>>>> >>>> >> -- ***************************************************************** 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]