6.2.3.5 Policy Representation

Here, the enhancements necessary for the adequate representation of metapolicies are described. In addition to this, it is discussed which part of the NoCScontrol system must be altered to use the enhanced representation possibilities. An exception is the Policy Interpreter, which will be discussed in the metapolicy enforcement.

Subjects

The semantics of the subjects in the policy specification with the PDL is somewhat in between the semantics used in authorisation policies and obligation policies. Authorisation policies state whether a subject is allowed to do something and in the case of obligation policies the subject is obliged to do something.

In the NoCScontrol system, the subject is used to check whether a policy must be enforced. The subject specifies the home domain of a nomadic system. When an event is caused by a nomadic system its home domain is compared to the specified subject of each policy. Matching of both the subject and the home domain causes the enforcement of the policy. An event is for instance the request to use a special resource, as printers, email, etc. This means that actions are taken for granting access of the nomadic system. The subject is at least additionally^6.5 used for stating an authorisation policy, but in the same policy actions are taken for granting access.

As a consequence of the nomadic computer system scenario, there is no concept of roles. The roles are necessary to state for instance the responsibility of actions.

Another result is the implicit restriction that the subject specifies the home domain of a nomadic computer system is not valid any longer.

Targets

At the moment, all management actions specified in the action part of a policy are executed on the specified targets.

Only one type of targets can be specified through the CORBA Naming and Topology Service. If the subject is a role and thus responsible for actions, these actions are not necessarily invoked on only one type of targets. Each management operation can be invoked on different managed objects. This is necessary for supporting the creation of management operations on the Metapolicy Service Mobile Agent as mentioned before.

Events

The use of an additional Event Definition Language (EDL) [Koch 97] adds flexibility to the system. Unfortunately, the Policy Service must be enhanced to support the EDL. The EDL allows the specification of events separately from the policy specification. In conjunction with the Metapolicy Service Mobile Agent, the EDL can also be used to specify the events the Metapolicy Service is sending.

Constraints

As a consequence of changing the semantics of the subject, checking of the home domain is done with an additional constraint expression, which regulates the enforcement of a policy.

The discussion of the invariant properties of passive policies has shown the importance of adequately specifying the policy. For this purpose predicates must be available as can be seen in the invariant example in table . When adding new state variables to the Metapolicy Service Mobile Agent, adequate primitives for implementing the necessary predicates must be considered.

The Metapolicy Service Mobile Agent implements a large number of additional predicates, because it holds the states of components and objects. These states are notified by events and saved by the Metapolicy Service. Therefore, it is a central component which can provide these predicates and constraints. The advantage is that not every metapolicy must re-implement complex constraints again.

Let´s consider the example when two actions are in execution and a metapolicy wants to prevent the execution of a third one. The beginning of the execution was notified by the actions and recognised by the Metapolicy Service. The Metapolicy Service also provides a predicate inconcurrence(Action A, Action B). This can be used in the specification of the constraint part of the metapolicy to decide whether the third action can be executed.

The Constraint Interpreter by the Enforcement Object Factory Mobile Agent (figure ) must be able to process and evaluate the stated constraints. Therefore, it must be enhanced to allow the constraint evaluation in cooperation with predicates of the Metapolicy Service. The Constraint Interpreter makes use of a decision service provided by the metapolicy agent. This service evaluates the potentially complex predicates for the Constraint Interpreter. This prevents the repeated implementation of the predicates and allows their central management. In a later step, this service could probably be separated out into a stand-alone component. This would allow normal policies to use this service for their purposes.

Actions

The Action Interpreter (figure ) is enhanced to allow the use of methods of every CORBA server as an action. Multiple actions from several services can be used. The realisation of conditional actions adds convenient flexibility. Future enhancements can add concurrence and job control.