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

I don't think separation into S, A, R and E is useful conceptually. That 
is implementation specifics.

There will be cases when Obligations change attributes not used in 
evaluation. So you will need a list of these separately.


David Chadwick wrote:
> Alex
> first of all there can be multiple specialised PIPs, to pick up 
> subject, action, resource and environment attributes, and additional 
> PIPs to pick up obligation related data. Only the latter will need to 
> lock the attributes. So when XACML returns the complete set of 
> attributes that are needed we can rule out the S, A, R and E ones 
> immediately as they wont need locking by their PIPs. They will be read 
> only. Only the coordination ones will need reading and locking by the 
> specialist obligation PIP. So I dont think we have a problem if the 
> PDP returns which attributes are needed for evaluating each request 
> context
> regards
> David
> Oleksandr Otenko wrote:
>> Do you also lock the attributes used in Obligations? Does XACML allow 
>> to return those? Does XACML allow to distinguish the use of 
>> attributes (r for decision-making, w for Obligation enforcement). If 
>> either of the answers is "no", we've got a problem.
>> Alex
>> David Chadwick wrote:
>>> 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

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