Existing solutions

The language that is going to be used in the configuration files to describe policy rules must be readable to a human and not too difficult to grasp its meaning. To make it readable means to use the plain text character set. It can be read by a large variety of editors across all platforms. When remote administration is needed, the plain text character set insures the best compatible solution.

Boolean expressions

One of the approaches that have been considered are boolean expressions. All requirements are met. However, there is one drawback of using boolean expressions; they get more complicated as the length of the expression grows. For example, the boolean expression:

2#2

is quite easy to interpret and understand. The story is all together quite different for the following expression:

3#3

Therefore we have decided not to use boolean expressions as our configuration language.

Policies in a Generic AAA Environment

In [2], a generic policy language is described. In essence, the language is still a boolean expression. The basis of the language is that of the form: `if condition then action', where the condition is a boolean expression in k-DNF form. For our purpose, the action is of less interest to us. For us, it is the modules (a tuple from the k-DNF expression) that performs the action and at the same time provide the condition. To conclude, we did not choose this solution because:

1. boolean expressions are the core of the language, making it harder to read;
2. the `if condition then action' does not map to our domain as well as we would like.

A Policy Description Language

In [1], Lobo describes yet another approach to a Policy Description Language. This is much the same as A. Taal does in: Policies in a Generic AAA Environment. This approach is less expressive. Therefore based on the same reasons as mentioned above (section 3.1.1), this approach is not pursued any further.

PAM

As stated in the previous section, using a human readable format is not enough. The language itself must also be easy to interpret by a human. One such solution is PAM (Pluggable Authentication Modules). Within PAM the success of a module is either: required, optional or sufficient. The meaning of each conditional is the following:

required

this module must return success in order to have the overall result be successful;

optional

if this module fails the overall result can still be successful if another module in the stack returns success;

sufficient

if this module is successful, skip the remaining modules in the stack, even if they are labeled as required.

This is in conflict with requirement rq:paths. When it is sufficient for a module to succeed, PAM exits and returns TRUE to indicate that it has successfully exited. One cannot, based on the success of the sufficient module, evaluate additional modules. Only on the failure of the module, will PAM continue with the next listed module on the stack.

0