6.2.3.1.2 Possibilities for Realising Passive Metapolicies

This could happen in various ways and three possibilities are presented and discussed here.

1. The enforcement of passive policies could theoretically be simulated with the help of active policies, as shown by the following description:
   1. Each operation of the management system is guarded by an active policy. So it is only possible to execute an operation if the event which guards this operation is received. After execution of the operation, all events which could trigger these kinds of active policies are deleted in the system and an event is sent which notifies the terminated operation and the system state.
   2. Each passive policy is translated into an active policy which sends the events of all valid operations that can take place. The state of the system is encoded into one event which triggers this policy. This means that potentially $2^n$ events must exist if the system state can be described by $n$ boolean state variables. This kind of policy is enforced before the one which guards the operations to ensure that all valid operations are permitted and executable.

   3. Only one operation is allowed to be executed at a time and the operation of the system is entirely described by passive policies.

   It is immediately clear that this is not an implementable solution for supporting passive policies, because the system must be heavily altered and causes a large number of events. Also the requirement that the entire operation of the system is described by passive policies is not practical.

   On the other hand, it shows in principle how passive policies could be realised. Whenever the management system wants to execute an operation, it must check whether there is a passive policy which would restrict the operation. This helps to find a better realisation.

2. In the item above, we have seen that before an operation takes place, it must be declared as valid through a passive policy. The system checks the metapolicies whenever it wants to execute an operation which could change the system state. The point when this must be done is called the decision point in the remainder.

   Practically speaking, it would be possible to add to each operation a check of its compliance with the stated passive metapolicies. This could be done by calling a special method of the management system or by sending a special event at each decision point. The decision point would be just before the actual execution when the operation knows its parameters. This is necessary, because both the operation and the method which checks the compliance must know the context of the actual execution. The context will include at least:

   operation

   This is the name of the operation which is executed if approval is given.

   affected objects

   The objects affected by this operation are listed to check whether there is a metapolicy which states something about them.

   values of the attributes

   The actual values of the attributes of the objects which will be used by executing the operation.

   The first two items of the context are needed to find all metapolicies which must potentially be applied and the last is used to check its conformance with the actual values used by the operation.

   A good idea is to also specify the context of a metapolicy in its representation. This enables a more effective search for all metapolicies which must be considered.

   The method which checks the compliance of the operation would give approval or deny the execution of the operation. In case of using an event mechanism, which includes the sending of the context, an event would be sent back to the method permitting or denying the execution.

   The system and the operations, must be trusted in the way that each operation must implement the request for execution and if the execution of an operation is not permitted it will not be executed.

   A variation of the principle described above is the introduction of a centralised method which controls and wraps each operation invocation, like a scheduler in an operating system. However, this scheduler does not consider time slices but the passive metapolicies. As a result, many of the already implemented methods need not be altered. This scheduler also needs the same information as described above, i.e. the context of the operation being executed.

   Not considered here are solutions which use a variation of the two-phase commit protocol, which means that the operation is executed and afterwards the state is checked with the constraints of the metapolicies. If no objection is raised the changes are kept, otherwise they are undone.

3. A less flexible approach is to translate the passive metapolicies into static configuration files whenever possible. A very easy example is to generate an access control list for all passive metapolicies governing the access rights to the policy descriptions. This is only useful if an access control list is used for granting access.

   This approach cannot handle all sorts of passive metapolicies. An example is the chosen metapolicy from the paragraph before, except when can be ensured that some operations do not violate the invariant. In this case, a list of operations compliant with the metapolicy could be used for taking the execution decision.

Figure: Spectrum of policy decision mechanims

It is clear, that the second and third items are two extremes. A real system could implement a mixture of these two, which would enable to consider time critical and flexibility aspects. Also using semi-translated/transformed passive metapolicies seems to be a possible solution, where not all details are static as figure  shows.

In general, all these enhancements to support passive metapolicies would also make it possible for the system to use passive policies with minor changes, because the basic concept of passive policies and passive metapolicies is the same.