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