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: XACML Obligations - a concurrency model


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]