Design

Our solution is to envision the policy rules as a Deterministic Finite Automata (DFA). DFAs are composed of states and transitions from one state to another. Precisely one of the states of a DFA has to be a starting state. This state is identified by an arrow, with a filled disk attached to the beginning, pointing to the start state. There is always exactly one start state per DFA. Also, a DFA has at least one end state. These are drawn with an inner circle. Unlike start states, a DFA can have more than one end state. Transitions are drawn as arrows originating from, and pointing to, a state. Transitions only happen when the conditions for the transition have been met. When no more transitions can be made, the DFA is said to have been terminated. If it terminates in an end point the DFA has succeeded, if not, it has failed.

Normally, a transition can be anything. In our case however, we know that there are only two possible transitions: TRUE or FALSE. We can use this a priori knowledge in designing our language, i.e. we do not have to specify the transition type; it is either TRUE or FALSE. Also with regard to termination of the DFA, we do it slightly different. When the DFA reaches an end state, the evaluation of that state determines the success or failure of the DFA. This is in contrast to reaching an end state and reporting success. One can view this difference as a compression. This way one less state needs to be drawn.

DFA example

The following figure illustrates a DFA in which three states 4#4 need to be visited. In each state a different module is evaluated and the result is used for the transition. Since we are only interested in successful evaluations, the transition only takes place when a module returns TRUE. Given the following DFA:

Figure 1: Simple DFA containing three states and only one TRUE transitions.

[scale=.6]figures/example1

we can say that the policy rule has succeeded when the module in state 5#5 returns TRUE. Should the result be FALSE for the states 6#6 then the policy rule has failed. When no transition can be made, the DFA terminates in that state and the policy rule has failed.

Of course a FALSE transition is also possible. We do need to make clear that a transaction needs to take place on the FALSE condition. Therefore we introduce the letters T and F to denote TRUE and FALSE respectively. The following figure shows a DFA containing a FALSE transition.

Figure 2: Simple DFA containing three states, two TRUE and one FALSE transitions.

[scale=.6]figures/example2

The way this DFA should be read is as follows: 7#7 must succeed and either 8#8 or 5#5 must succeed.

In case the evaluation of 8#8 is TRUE, we do not need to evaluate 5#5, because 8#8 is marked as an end state. The policy rule has succeeded with the successful evaluation of 8#8. Only when 8#8 returns FALSE, is the transition from 8#8 to 5#5 made and determines 5#5 the success or failure of the policy rule.

Policy example

Figure fig:real_example shows a real example of a policy. Sites which wish to give precedence to localaccounts over poolaccounts might want a policy like this. The policy checks if the user may use a localaccount first. If this is allowed, the policy then checks for posix enforcement. When all is okay, the policy has succeeded, otherwise it has not. However, it is possible that the localaccount does not allow for a local account because, the user has no local account at all. In this case the site policy tells that the poolaccount needs to be checked. When the poolaccount is successful, the voms will be checked. At last, the same posix enforcement need to be done as before. Only when the posix enforcement is successful, will the policy have succeeded.

Figure 3: Real example.

[scale=.6]figures/example_real

In the above example the DFA starts at the localaccount. By letting it start at the poolaccount state and inverting the direction of the transition between localaccount and poolaccount, precedence is given to poolaccount instead of localaccount. Thus, even when a user has a local account, the system prefers pool account. This shows how system administrators are able to decide what happens on their system.

The language

DFAs give us a reasonable clear language to express policy rules. However, this is in direct violation of requirement pdldepth 0pt width .5em. We need to translate the DFA into plain text.

In order to describe the DFA, we only need to specify the transitions from one state to another. We use the ` 9#9' symbol to indicate a transition. Thus 10#10 means the transition from state 7#7 to 8#8. From this notation it is not clear what the condition of the transition is. Unless stated otherwise, the default condition of a transition is TRUE. With these rules, the DFA of Figure 1 translates into:

11#11

If the DFA contains a FALSE transition, then we need to tell that we do not want to use the default TRUE transition. This is accomplished by prefixing a tilde to a transition line. Thus, Figure 2 translates into:

12#12

This kind of language is easily translated into plain text. The ` 9#9' symbol can be written in plain text as: `->'. For typographically reason we will use the ` 9#9' symbol throughout this document. The language just describes can also be written down into Extended Backus Naur Form (EBNF). We use the following definitions:

• `13#13' denotes zero or more repetitions;
• `+' denotes one or more repetitions;
• '14#14' denotes a choice;
• anything between quotes (') is taken as literal;
• reserved words are printed in bold.

Using the above definitions, we can express our language as follows:

15#15

The above reads: a policy contains at least one rule; a rule can be one of three forms; a term is composed out of characters, digits, underscores and punctuations.

Policy example

With the above definitions, the policy as described in § 4.1.1 is thus written:

16#16

As one can see, this is fairly simple to interpret and understand. It also meets all requirements we have set ourselves.

We would like more flexibility in the language. Thus, the basic idea will be extended. First, we will show some more complex artificial examples to demonstrate the ease of the language.

More elaborate DFAs

We will give two more examples of a DFA. This is to show that rather complicated policies can be written down in an understandable fashion. Suppose we have the following DFA:

17#17

This would translate into:

18#18

Even though the DFA has six states, the configuration file does not look overwhelming. Which is what we are looking for.

As a last example we give the following DFA:

19#19

Again, this is translated into the following policy rule:

20#20

Still, the configuration file looks comprehensible despite the fact that several TRUE/FALSE transitions are present.

Extending the language

What we have described thus far is a very basic language. It does all that we need. Though, we would like to take it one step further. First of all, we would like to be able to use free variables. This allows us to use simpler naming in the policy rules. A free variable is defined as follows:

21#21

However, spaces are not allowed in this form, since a term cannot contain a space. If spaces are needed, the term needs to be a string:

22#22

A string is defined as the following regular expression:

23#23

The string matches any sequence that starts with a double quote, followed by any character that is not a newline and closed by a double quote.

Sites might want to have more than one policy rule. Thus, we add the following line to the definition:

24#24

This gives every policy rule a label, thereby grouping them and being able to refer to each individual group. Now that policies are labeled we would like to have the ability to use a policy rule inside a policy rule. This means that a `term' can also be a `policy':

25#25

All modules are stored at the same location. Therefore we have reserved one name: path. This is a special variable. It needs to be followed by the assignment character (=) and a Unix path.

26#26

The following regular expression defines paths:

27#27

Last but not least, we would like comments as well. A comment is defined in the following manner:

28#28

Given our original specification together with the above extensions, the complete EBNF notation for the language is:

29#29

Policy example

Given the definition of the language in the previous paragraph. We can write a configuration file for the example in Figure fig:real_example:

• [numbers=left, frame=single, commandchars=\\\{\}]
  #  Configuration example in which local accounts are
  #  preferred over pool accounts.
  
  #  First we define the path where the modules can be found.
  path = /opt/edg/lib/lcmaps/modules  \label{lst:path}
  
  #  Let us now define the variables.
  local = "lcmaps_localaccount.mod -gridmapfile /etc/grid-security/grid-mapfile" \label{lst:var_begin}
  pool  = "lcmaps_poolaccount.mod  -gridmapfile /etc/grid-security/grid-mapfile"
  voms  = "lcmaps_voms.mod         -vomsdir /etc/grid-security/certificates
                                   -certdir /etc/grid-security/certificates"
  posix = "lcmaps_posix.mod        -maxuid 1 -maxpgid 1 -maxsgid 32"             \label{lst:var_end}
  
  #  We have one policy rule that is called default.
  default:                                                     \label{lst:policy_label}
  local -> posix | pool  # See of local and posix do the job.  \label{lst:policy_local}
  pool  -> voms          # If not: pool, voms and posix        \label{lst:policy_pool}
  voms  -> posix         # need to do it.                      \label{lst:policy_voms}
  

The first interesting line to look at is line 5, we see the use of the reserved word path. Here the path is defined where the modules can be found. Lines 8 - 12 define four variables. Each variable is a module with its arguments. These variables are used in the policy rules as can be seen on lines 16 - 18. Line 15 defines the name of the policy.

Final words

As one can see, policies in the graphical form of the DFA are quite easy to comprehend. On the other hand, translating from the graphical from to plain text is quite easy to do and not error prone. The resulting configuration file is still easy to interpret and understand. Mistakes completely eradicated. However, mistakes are less likely to be made by drawing a DFA and then translating it. As a bonus, one can easily create a GUI for creating and maintaining the policy rules.

0