The definition of access conditions involves two steps:
Defining the subject types to which the conditions are to apply; permissible subject types are USER, GROUP, OTHERS and the GUARDS pseudo-subject ALL-USERS
Defining the actual access conditions
In order to formulate access conditions optimally, the user must be familiar with the logic of the condition evaluation. For condition evaluation, GUARDS sorts the conditions and their evaluation by subject types. Evaluation for the subject type USER, GROUP or OTHERS is aborted as soon as the first hit is found. The evaluation can return only one of the two possible results, namely TRUE (conditions are fulfilled) or FALSE (conditions are not fulfilled).
Entries for the subject types USER, GROUP, OTHERS and ALL-USERS are optional. If no conditions are defined at all, the result of evaluation is always FALSE. An empty guard exists, for example, in the interval between creation of a guard with the /CREATE-GUARD command and the definition of the first condition with
/ADD-ACCESS-CONDITIONS or after all definitions have been deleted from a guard with /REMOVE-ACCESS-CONDITIONS.
Evaluation for the subject types is carried out in the following order:
USER
The conditions for USER are evaluated first. These contain the conditions which apply explicitly to a specified user ID. The name of a user ID, as defined with ADD-USER, must be specified as a parameter. Evaluation begins by searching through the USER entries to determine if one exists for the user ID for which a check has been requested. If a match is found, the conditions stored for this user ID are evaluated.
If the result of the evaluation is TRUE, the conditions for the subject type ALL-USERS are evaluated next.
If the result of the condition evaluation is FALSE, evaluation is aborted and GUARDS returns the result FALSE to the object management system which initiated the inquiry.
GROUP
This addresses the conditions which are to apply explicitly to a user group. The name of a user group, as defined with ADD-USER-GROUP, must be specified as a parameter. If no matching USER entry was found, the evaluation logic searches through the entries for GROUP to determine whether one exists for the user group to which the specified user ID belongs. If a match is found, the conditions stored for this user group are evaluated.
If the result of the evaluation is TRUE, the conditions for the subject type ALL-USERS are evaluated next.
If the result of the condition evaluation is FALSE, evaluation is aborted and GUARDS returns the result FALSE to the object management system which initiated the inquiry.
OTHERS
This addresses the conditions which are to apply to all users not covered by entries for USER or GROUP.
If the result of the evaluation is TRUE, the conditions for ALL-USERS are evaluated next.
If the result of the condition evaluation is FALSE, evaluation is aborted and GUARDS returns the result FALSE to the object management system which initiated the inquiry.
If a guard does not contain entries for the subject type USER or for GROUP or OTHERS, the result of the evaluation is always FALSE.
ALL-USERS
This is a pseudo subject script by means of which additional conditions can be stored that are only evaluated if the previous checks for USER, GROUP and OTHERS have led to the result TRUE.
In this way, access conditions can be entered in a guard that apply to all the subject types and subjects specified in the guard. They do not have to be specified for each individual subject type.
Example
In a guard it has been specified under the subject type USER for the user IDs PETER, PAUL and MARY and under the subject type GROUP for the user group TEAM that access is permitted. You use the subject type OTHERS to specify that all others do not have admission.
% User PAUL has ADMISSION % User PETER has ADMISSION % User MARY has ADMISSION % Group TEAM has ADMISSION % Others has NO ADMISSION
Access is also to be prohibited for a short period for the subjects specified under USER and GROUP (PETER, PAUL, MARY, TEAM). To avoid having to change all the relevant access conditions to ADMISSION=*NO, you use the pseudo subject type ALL-USERS. You then only have to specify the access condition
ADMISSION=*NO once, and it applies to all users:% User PAUL has ADMISSION % User PETER has ADMISSION % User MARY has ADMISSION % Group TEAM has ADMISSION % Others has NO ADMISSION % Alluser has NO ADMISSION
For example, if the subject MARY accesses a protected object, once the first protective hurdle is cleared (TRUE), the additional ALL-USERS check is carried out and returns the result FALSE. If a subject that does not fall into the category USER or GROUP accesses a protected object, the OTHERS check is carried out and returns the result FALSE. In this case, the check is terminated without the ALL-USERS check being carried out.
Figure 19: Logical evaluation of access conditions by subject types
Note
The access conditions specified for the subject type USER, GROUP or OTHERS (condition a) and those for pseudo-subject type ALL-USERS (condition b) are logically ANDed. This means that access is only permitted when both condition a and also condition b are satisfied. GUARDS does not perform any check when access conditions are defined as to whether conflicting conditions exist. The owner of a guard must therefore check carefully whether inconsistencies exist between the access conditions for the subject types USER, GROUP or OTHERS on the one hand and those for the pseudo-subject type ALL-USERS on the other. Such inconsistencies can result in an access being rejected when it should actually be permitted.
Example
The access condition for the subject type USER specifies a period from 08:00 to 13:00, the condition for ALL-USERS however defines a period from 12:00 to 18:00. Access for a user specified in the condition for USER is permitted only when both conditions are satisfied. In this example this is the case from 12:00 to 13:00. If an access were attempted by the user at 9:00, this would however be rejected even though the condition for the subject type USER is satisfied.
But this behavior can also be desirable, for example in order to globally lock an object for a certain period of time. It therefore falls within the responsibility of the owner of a guard to decide whether or not undesired contradictions are present.
Example for the use of ALL-USERS
Access to a file is only to be permitted via the program EDT.
The condition “access only via the program EDT” is specified only for the pseudo-subject type ALL-USERS.
Definition for USER:
|
Definition for GROUP:
|
Definition for OTHERS:
|
Definition for ALL-USERS:
|
Although the condition “access only via the program EDT” is specified neither for USER, nor for GROUP nor OTHERS, the access is controlled in the desired manner by way of the condition entered for ALL-USERS.
In addition, the user EDTUSER is to be allowed file access via the program SORT:
|
For the user under the user ID EDTUSER, the conditions continue to be TRUE when the user uses the program EDT to access the file protected with the aid of GUARDS. However, if the user attempts to access the file by using the program $SORT, the evaluation of conditions by GUARDS will yield FALSE as the test result since the access condition for ALL-USERS permits access only via the program $EDT. GUARDS does not check the conditions in a guard for consistency; it is the responsibility of the owner of the guard to determine whether or not such inconsistencies are deliberate.