Pre-, Mid-, Post- and Request-result Conditions

An authorization policy may specify conditions that must be satisfied before, during or after the access right is exercised. Furthermore, evaluation of some conditions must be activated only if the authorization request is granted (or denied).

Thus, all conditions are classified as:

• pre-conditions specify what must be true in order to grant the request. This means that the requested operation is allowed to be executed on the target object. If any of the pre-conditions fails, authorization is denied.

• request-result conditions
  These conditions must be activated whether the authorization request is granted or whether the request is denied.

• mid-conditions specify what must be true during the execution of the requested operation. The mid-conditions can be used for the protection of the critical operations and resources. The mid-conditions allow for real time active monitoring of the operation execution and response. If any of the mid-conditions fails, the operation execution must be affected. The countermeasures are defined in the response methods of the target object. Aggressive responses may include direct countermeasures, such as closing the connections or suspending the processes. This is important to enforce counter measures against serious attacks. For example, a processes consuming excessive system resources (CPU time, memory, and disk space) may indicate impending denial of service attack. More passive responses may include the activating of integrity-checking routines to verify the operating state of the target.

  The mid-conditions that we consider in our framework are limited to a set of thresholds, such as duration of connection, CPU and memory usage and severity metrics (e.g., current system threat level).

• post-conditions specify what must be true on the completion of the operation execution. The post-conditions can be specified in two ways:
  1. The post-conditions that are activated only if the requested operation succeeds. These conditions are useful to correctly implement the enforcement of, for example, the payment/quota constraints.

     Here are some examples of the policies with post-conditions:

     ``A user must pay $1 to read a file. The money must be withdrawn from the user account only after successful file access.''

     In this policy, the payment condition must be implemented as a post-condition. If the file read fails for technical reasons (the server crashes in the middle of the read operation), the payment condition is not activated and the user does not lose his money.

     ``A user is allowed to access file 5#5 only once.''

     Similarly, the quota condition in this policy must be implemented as a post-condition to ensure that the user can access the file at least once.

  2. The post-conditions that are activated only if the requested operation fails. For example, failure of critical operations, such as system shut down may indicate denial of service attack and require immediate notification.

The post-conditions along with the request-result conditions are useful to fine tune audit and notification services.