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


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]