To protect the permissions established in the permissions table, you can provide the security administrator with the following procedures:

  • A procedure that defines who can modify the permissions table. Initially, you can run this procedure and enter the user ID of the security administrator, as well as database connection IDs of those authorized to modify the permissions table.
  • A security update procedure (for example, i-secupd.p) that the security administrator or other authorized users can run to modify permissions for specific procedures and functions.

To do security checking, these procedures require a record in the permissions table associated with the activity of maintaining security. The following figure shows an example security record in the permissions table.

Figure 1. Sample security record for activity permissions


When you create the security record, initialize the can–run field with an asterisk. This means that, initially, any user can run the security administration procedure (i-secadm.p). However, after you run it and enter the authorized user IDs, only the authorized users can change the security record.

i-secadm.p

/* Security checking */
FIND permission "security".
IF NOT CAN-DO(can-run) THEN DO:
  MESSAGE "You are not authorized to run this procedure.".
  RETURN.
END.

/* i-secadm.p */
DISPLAY "Please enter one or more security ids for the security
 administrator, separating the ids with commas" SKIP(1).
UPDATE can-run.

The authorized users can also run the next procedure, i-secupd.p, which updates permissions for procedures and activities.

i-secupd.p

/* Security checking */
DO FOR permission:
  FIND permission "security" NO-LOCK.
  IF NOT CAN-DO(can-run) THEN DO:
    MESSAGE "You are not authorized to run this procedure.".
    RETURN.
  END.
END.

/* i-secupd.p */
REPEAT FOR permission:
  PROMPT-FOR activity.
  FIND permission USING activity.
  UPDATE can-run.
END.

The first part of i-secupd.p checks the security record in the permissions table to make sure that the user is authorized to run the procedure. If the user is not authorized, the procedure displays a message and exits. Otherwise, the second part of i-secupd.p permits the user to modify the can–run field for a specified activity.

The following figure summarizes the security process developed for procedures and functions in an application.

Figure 2. Summary of run-time authorization process