[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] XACML Obligations - a concurrency model
Hi Alex we can link the lock with the unlock by the PIP recording the transaction ID in the request context as an environmental attribute (and the PDP ignores it), but the obligation uses it to know which lock to release. Even if it is a per PDP lock there might still be other PDPs locking other parts of the coordination database at the same time, so the transaction ID is still needed to be passed. regards David Oleksandr Otenko wrote: > I think the issue is more complex than that, as you need to lock the > attributes used in Obligations, too, and there should be a mechanism to > link the lock with unlock, if the implementer were to go that way. I > think the support for transactional model for decision-making should be > evaluated, if it wasn't already. > > The effect of per-policy vs per-PDP call locking depends more on the > number of concurrent requests than the size of the policy. But I guess > this is more of an implementation issue. > > > Alex > > David Chadwick wrote: >> Hi Alex >> >> yes you are correct. XACML already has elements for returning the >> attributes that are needed, in response to a decision request. >> Alternatively, we implemented a method GetAttributes that can be >> called on the PDP by the PEP at anytime (but usually at start up) to >> get the full set of environment attributes in the policy. This is ok >> for small policies but not for large ones where a per user request >> return is needed. So there is a trade off here, which someone would >> need to experimentally measure, to see at what policy size the per >> call becomes more efficient that the per PDP return of attributes. >> >> regards >> >> David >> >> Oleksandr Otenko wrote: >>> Thanks, Rich. I wasn't implying the PDP needs to understand >>> transactions, but someone has to, and that is more likely to be the >>> entity enforcing the obligations. On the other hand, it is not the >>> obligation enforcer that obtains the values of the attributes used >>> for access control decisions. It is probably the PIP that has to lock >>> the attributes, but it is the Obligation Enforcer that has to unlock >>> them. >>> >>> Transaction coordination is an important task that requires close >>> interaction with and between the P*P entities. For example, currently >>> there is no way of knowing which attributes to lock, for what purpose >>> (r/w), and for how long. Trivial solutions cause problems. The best >>> solution would be to refine the policy set based on the request, to >>> feed back what attributes need locking for update before a decision >>> is made, and what attributes might need locking for reading until the >>> obligations are enforced (which also need locking prior to >>> decision-making). The careful definition of "before, with, after" >>> temporal constraints could address the "how long" part. >>> >>> >>> Alex >>> >>> >>> Rich.Levinson wrote: >>>> Hi Oleksandr, >>>> >>>> I am working under the assumption that the PDP does not maintain its >>>> own database of attributes, so therefore, I am assuming that the >>>> account balance Attribute you are referring to is maintained by some >>>> system or combination of systems external to the PDP, and that if >>>> the PDP has to obtain a value for this attribute that it has a way >>>> thru the logical ContextHandler to obtain it. >>>> >>>> I am also assuming that when the PDP obtains an Attribute thru one >>>> of its access channels (i.e. either in the initial request, or >>>> somehow thru ContextHandler reaching out and obtaining thru some >>>> proprietary mechanism (i.e. some mechanism not defined or even >>>> identified in the XACML spec)), that it can safely assume that the >>>> value of that Attribute has been delivered in a reliable manner >>>> (integrity for certain, and presumably confidentiality) from a >>>> trusted source (provider of that particular kind of Attribute). >>>> >>>> Given those assumptions, the PDP can process the Attribute without >>>> needing to do any "second-guessing" as to whether the Attribute >>>> should be used or not. It is what it is, and will be used as >>>> delivered and Policy logic should determine whether the Attribute >>>> meets whatever conditions are required of it for any possible value >>>> that is delivered for it. i.e. either the Attribute is within the >>>> ranges allowed for it or not. If outside the ranges, then >>>> appropriate exception handling should exist in the Policies to >>>> determine what to do based on that. >>>> >>>> Now, from what I gather from your use case description, the PDP is >>>> expected to return this Attribute in an AttributeAssignment element >>>> of an Obligation, possibly under some conditions it will return it >>>> and others not depending on Policy evaluation, but at least in some >>>> cases it can be returned. >>>> >>>> Trying to read a little more into the use case, I am assuming that >>>> this account balance can possibly be changed by the user if they are >>>> granted access, and that one wants to ensure that there are no >>>> timing windows thru which inconsistent results can get into the data. >>>> >>>> In general, to achieve this objective, one would need to "lock" the >>>> attribute for the duration of the transaction. In a distributed data >>>> base there are many strategies to provide this capability, however, >>>> I do not think that the PDP is an active player in the transaction, >>>> i.e. I would think the transaction "coordination" is being done by >>>> some entity external to the PDP. >>>> >>>> In this case, my sense is that for the PDP to safely read this >>>> Attribute, it is the responsibility of the transaction coordinator >>>> to first initiate the transaction and lock any Attributes needed for >>>> consistency of the transaction, and that the authorization would >>>> take place within the bounds of the transaction. For example, if the >>>> PEP happened to be the transaction coordinator, I would expect the >>>> PEP would do some kind of "BeginTransaction", then issue the >>>> authorization call to determine if user is authorized based on the >>>> state of the data within the transaction, and, if so, then allow the >>>> user to complete the transaction and end it. >>>> >>>> In such a scenario, the PDP could obtain the Attribute and return it >>>> in an Obligation to the PEP and if that happens within the bounds of >>>> the transaction there should be no problem. >>>> >>>> Where I do see a problem is if it is assumed that by getting the >>>> Attribute, that the PDP is effectively taking on some role as >>>> transaction coordinator and taking some responsibility for the >>>> validity of the data. I think this would be outside the scope of >>>> intended functionality for a PDP. >>>> >>>> In this context, as described above, I don't see any reason that the >>>> PDP would need to be involved with the "before, after, or with" >>>> aspects of the handling of the Attribute. >>>> >>>> If I missed something about the use case that would change that, >>>> please let me know, I am only working with the information as I read >>>> it from your email. >>>> >>>> Thanks, >>>> Rich >>>> >>>> >>>> Oleksandr Otenko wrote: >>>>> Hi Rich, >>>>> >>>>> >>>>> Say the decision is based on a value of an Attribute (account >>>>> balance for a cloud computing user). A distributed system needs to >>>>> maintain the value, and update it coherently across multiple nodes. >>>>> Is this Attribute Assignment part of an Obligations spec or is it >>>>> considered business process logic? If it is going to be part of the >>>>> Obligations spec, the "after, with, before" are going to be, and >>>>> the synchronization mechanism needs defining. But as you said, this >>>>> is probably for later in this case. >>>>> >>>>> >>>>> Alex >>>>> >>>>> 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]