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