Refinements

In this section we describe further refinements of our basic entities. A policy statement may specify several conditions of different types, for example: ``Tom can read file 1#1 only between 9am and 6pm''. This policy defines two conditions: access identity and time. In () we have considered only one condition in the policy statement. All existing conditions were aggregated into one set (). Now we extend the notion of a condition to be distinguished not only by an identifier but also by a type. Each condition element has just one type. We assume that at each instant 78#78 condition types exist. We represent these different condition types by 78#78 disjoint sets:

79#79 (16)

Now we define a totally ordered set 80#80. Each element of this set is constructed from one element of the 78#78 disjunctive sets. Intuitively this means that each element of 80#80 consists of 78#78 condition elements of different types, some of the elements can be 16#16.

81#81 (17)

We define 78#78 condition evaluation functions for each condition type. In our policy example we define two function for checking access identity and current time.

82#82 (18)

From () and () we observe that if at least one of the policy statements evaluates to 26#26, the authorization will be granted. This behavior may not be always desirable. For example, we would want a policy assigned by the system administrator to take precedence over the one assigned by an individual user. This requires the means of specifying a hierarchical relationship among policy statements.

The hierarchy of policies is modeled by assigning priorities. We do not attempt to give a full theoretical development of the method of assigning priorities here. The essential requirements is that one should be able to decompose the whole policy into totally ordered policy statements. To express policy priorities, we define set 83#83. 83#83 is a finite totally ordered set of elements that can be compared (e.g., integers).

84#84

We redefine element 3#3, given in () in the following way:

85#85 (19)

We extend () in two ways: 1) each element 4#4 has an additional component 86#86, which denotes priority of this element. 2) condition component is represented by a set of 87#87 condition constants of different types.

88#88 (20)

Figure 1 illustrates representation of a policy element 4#4.

89#89


Figure 1.

The 90#90 function takes a set of policies 9#9 as an argument and returns a subset 74#74 with the maximum priority. The ordering in the set 83#83 determines the policy statement which is enforced if several policy statements are simultaneously satisfied. Note that if the set 91#91 contains more then one element, the elements have equal priorities. In this case, if any of the policy statements is satisfied, authorization is granted.

92#92

93#93 (21)

We redefine 41#41 function given in () in the following way:

94#94

95#95

96#96 (22)

The 41#41 function is a short hand notation for representation of conjunction of the results, obtained by applying 97#97 to corresponding condition constants from the policy element 4#4. All conditions must be met simultaneously in order to satisfy the authorization request.

The resulting value 55#55 obeys to the 98#98 operation for three-valued logic. That is, 41#41 returns 26#26 if all elements gave the result 26#26, 27#27 if at least one result was 27#27, and 28#28 otherwise (i.e. at least one result was 28#28, possible some 26#26 but none 27#27.

We redefine 57#57 function given in () in the following way:

58#58

99#99

100#100

101#101 (23)

Figure 2 illustrates the 57#57 function.

102#102


Figure 2.