Model 204 security features
Overview
A variety of security features provide Model 204 users with protection against unauthorized use of their account names, files, groups, records, fields, procedures, and terminals. This section describes the role of the file manager in maintaining Model 204 security.
Additional documentation on security features
- System manager responsibilities are described in detail in the Rocket Model 204 System Manager's Guide.
- In addition, Rocket Software has add-on interfaces between Model 204 and a number of security products. These security interfaces are described in the Rocket Model 204 Security Interfaces Manual.
Using the Model 204 password table
The Model 204 password table is the backbone to the security features in Model 204. The user must enter a valid password to access the Model 204 Online, files, groups of files, and subsystems, which in turn affects access to records. The security feature in Model 204 is not based on a hierarchy, but rather on direct password validation.
The password table, CCASTAT, is set up by the system manager. When the file manager determines which users or groups of users can have access to what data, then the file manager works with the system manager to correctly set up the password table and file access.
Types of security
All Model 204 security features are optional. A site can support any combination of features. The file manager is primarily responsible for file, group, record, field, and procedure security. Both system and file managers handle terminal security. The file manager's responsibilities are described in this chapter.
| Type of Security | Function |
|---|---|
| Login (System manager) | Limits access to the Model 204 system by requiring an individual user to enter a password when logging in. Only users who enter a valid password can gain access to the system. When a user successfully logs in, specified privileges are granted. See the Rocket Model 204 System Manager's Guide and the LOGCTL command for modifying user ID entries. |
| File (File manager) | Protects certain types of files by requiring a user to specify a valid file password in the OPEN command or OPEN statement. After successfully opening a file, a user is granted particular privileges pertaining to the data and procedures in that file, as well as a user class number for procedure security, and field-level security access levels. |
| Group (File manager) | Protects certain types of file groups by requiring a user to specify a valid group password in the OPEN command or OPEN statement. When a user successfully opens a permanent group, the user is granted specified privileges that pertain to the files in the group. When opening a temporary group, the user is granted the privileges that all the member files have in common. |
| Record (File manager) | Limits access to particular records in a Model 204 file. When record security is in effect, a user can retrieve and update only those records stored by the user's login ID or records that other users have agreed to share. |
| Field-level (File manager) | Protects sensitive fields in a Model 204 file. Field-level security levels are granted when opening a file or group, and they indicate the type of access (for example, READ, UPDATE) to the field that the user is allowed. |
| Procedure (File manager) | Limits access to the procedures in a file. It indicates whether a user is authorized to access particular procedures and specifies the type of access (for example, DEFINE, DELETE) that the user is allowed in secured procedures. |
| Subsystem (System manager) | Controls the privileges that are assigned to users who enter a subsystem. The system manager assigns users subsystem command privileges and privileges for each file and group in the subsystem. |
| Terminal (File and system managers) | Allows specified login user IDs and specified files and file groups to be accessed only from certain hard-wired terminals. |
File security
Model 204 file security features allow you to restrict access to particular files to designated users, as well as to limit the operations that can be performed on those files. Although you are primarily responsible for determining the file security scheme in a Model 204 system, you can allow users to change a password for a file if you provide them with the appropriate login privileges.
Security for files opened in a subsystem operates differently. See Subsystem security for more information.
File manager's responsibilities
Ordinarily, the file manager determines which files and file parameters to protect from unauthorized access and determines the initial passwords and associated privileges for the files. It is then the system manager's responsibility to add entries for these files to the password table. The password table contains password and privilege information for files, file groups, and login user IDs. Maintaining this table is discussed in the Rocket Model 204 System Manager's Guide.
Defining access levels for files
The file manager is responsible for defining the default access levels for public and semipublic Model 204 files. You are also responsible for determining the four access levels that belong with each file or group password. These levels are then added by the system manager.
File privileges
File privileges determine the type of operations that the user is authorized to perform on the file that is being opened. The types of files are:
| If the file is... | Then Model 204... |
|---|---|
| Public | Opens the file without asking for a file password and grants the user default file privileges as specified by the PRIVDEF parameter. |
| Semipublic |
Prompts the user to enter a valid password:
|
| Private |
Prompts the user to enter a valid password:
|
OPEN command and OPEN statement
For a discussion of the OPEN command and the way in which a user specifies a password when opening different types of files, refer to the Model 204 Parameter and Command Reference. The OPEN statement is described in the Rocket Model 204 User Language Manual.
Creating files with file security
[!!!make tasks here!!!]
When a file is first created with the CREATE command, you can limit access to the file by setting two system parameters, OPENCTL and PRIVDEF, and by asking the system manager to enter one or more file passwords in the password table. Also, the OPENCTL and PRIVDEF parameters can be reset at a later time.
The following sections provide a further description of file passwords and privileges, as well as the OPENCTL and PRIVDEF parameters.
File passwords and privileges
You can define several passwords for a file. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the file by the user who opens the file with that password.
If you do not specify values for OPENCTL and PRIVDEF when you create the file, the file is assumed to be a public file that has a full set of default file privileges. This implies that any user can open the file using the OPEN command or OPEN statement without having to enter a file password, and can then retrieve and update data, define and run procedures, or access file parameters.
Creating passwords
Passwords can be up to eight characters long and cannot contain blanks, commas, or colons.
OPENCTL parameter
The OPENCTL parameter determines whether or not a user must enter a file password when opening the file. Except as specified in the following table, OPENCTL settings can be added together. The first three settings are mutually exclusive and one of them must be included in your OPENCTL specification. The remaining settings in the table are options that you can add to one of the first three settings.
| Setting | Means file is... | Password handling |
|---|---|---|
| X'80' | Public |
Password is not requested and the file is opened with default privileges. This setting cannot be combined with X'40'. |
| X'40' | Semipublic |
User is asked for a password. For a valid password, the user is given the associated privileges. Otherwise, the user is granted default file privileges. This setting cannot be combined with X'80'. |
| X'00' | Private | Without a valid password the file is not opened. |
| X'20' | Using record security |
No effect. The user must have a security level that permits some type of access. |
| Additional options for Parallel Query Option (PQO) | ||
| X'08' | Accessible remotely without a valid password |
For a public file, no password is requested and the file is opened with default privileges. For a semipublic file, a password is requested. If the password is missing or invalid, the user is granted default file privileges. For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened if X'02' is set. |
| X'04' | Accessible remotely as a permanent group member | Model 204 permanent group security is in effect. Password handling for local users is unaffected. |
| X'02' | Accessible remotely with a valid password | For a private file, or a semipublic file that a remote user presents a valid password for, the file is opened. |
| X'00' | Accessible remotely through APSY | For any file, no password is requested and the file cannot be opened remotely, except within a trusted subsystem. |
For PQO sites, the OPENCTL parameter determines how a file can be accessed remotely. The PQO remote access settings have no meaning for local files. For more information about PQO remote files, see the Parallel Query Option/204 User's Guide.
PRIVDEF parameter and file privileges
The PRIVDEF parameter summarizes the default file privileges that are assigned when a public file is opened, or when a semipublic file is opened without a password or with an invalid password. Privileges can be set to any combination of the following bit settings. These privileges are identical to the privileges that can be specified for an individual file password in the password table.
| Bit | User can... |
|---|---|
| X'8000' | Issue file manager privileged commands such as INITIALIZE, SECURE, and DESECURE. The file manager can also reset file parameters, provided that ad hoc update privileges (X'2000') are obtained. |
| X'4000' | Override record security; see Record security. |
| X'2000' | Update data with ad hoc requests or host language programs. |
| X'1000' | Make changes to internal procedures, that is, procedures defined in the same file as the data, but cannot delete them. |
| X'0800' | Update data using internal procedures. |
| X'0400' | Retrieve data with ad hoc requests or host language programs. |
| X'0200' | Display, echo, and copy internal procedures. |
| X'0100' | Retrieve data with internal procedures. |
| X'0080' | Update data using external procedures, that is, procedures defined in a different file from the data. |
| X'0040' | Retrieve data using external procedures. |
| X'0020' | Include internal procedures. |
| X'0010' | Define internal procedures. |
| X'0008' | Delete internal procedures. |
| X'0001' | Access file related parameters. The affected parameters are described in Setting file parameters. |
PRIVDEF default setting
The default value for the PRIVDEF parameter is X'BFFF', that is, all privileges except the ability to override record security.
Combining PRIVDEF settings
Update privileges, for example, update using ad hoc requests, do not imply corresponding retrieval privileges. Thus, a user who has only the ability to update using ad hoc requests (X'2000' bit set) cannot find any records to update. A user must be given both update and retrieval privileges (X'2400') to update data effectively.
Similarly, privileges for data retrieval using internal procedures (X'0100') do not imply that the user can include a procedure from the file. The X'0020' privilege is required for this.
If procedure security is desired, you must relate procedure class numbers to the procedures stored in the file. Also, determine the field-level security levels for any fields in the file that are particularly sensitive and need to be protected against unauthorized access. Field and procedure security features are discussed in Field-level security and Procedure security.
Resetting PRIVDEF or OPENCTL
When the OPENCTL parameter is reset to X'80' (public), the assigned privileges are those of the current value of the PRIVDEF parameter. This means that if OPENCTL is reset to X'80' while PRIVDEF is set to less than full file manager privileges, you cannot update the file or reset any file parameters. This can also occur if you reset PRIVDEF while OPENCTL is set to X'80'.
To avoid this problem, use the VIEW PRIVDEF command to ensure that you have appropriate PRIVDEF privileges before you reset OPENCTL to X'80'. Be very careful about resetting PRIVDEF for a public file.
Regaining access
If you do accidently lock yourself out of a file, you can regain access as follows:
- Have the system manager create a permanent private group that contains the locked file.
- Have the system manager add a group password (and tell you that password) to the password table, CCASTAT, with the privileges X'BFFF'.
- Then, open the private group and issue one of the following commands:
IN FILE name RESET OPENCTL=X'40'
or:
IN FILE name RESET PRIVDEF=X'BFFF'
where name is the name of the locked file.
Securing and desecuring a file
Making files secure
Securing a file ensures that a user cannot access a file illegally by running a Model 204 program with a different password table. A special key in the password table serves as the key for securing a file. The key can be changed by the system manager with the LOGKEY command. When a secured file is opened, Model 204 compares the key to a copy placed in the file by the SECURE command. The file is opened if the two fields match. If the fields do not match, the user is logged out and an error message is displayed on the operator's console.
The SECURE command, which can be issued only by a file manager, provides additional file protection by securing the currently open file. This form of the command is issued without arguments:
Syntax
SECURE
Desecuring a file
To desecure a previously secured file, issue the command:
Syntax
DESECURE
For a description of using the SECURE and DESECURE commands with procedures, refer to Procedure security.
Group security
The Model 204 group security features allow access to particular file groups to be limited to certain users.The file manager is primarily responsible for group security and for the file security features discussed in the preceding section.
Group passwords
Ordinarily, the file manager determines which groups to protect from unauthorized access, and indicates the passwords and associated privileges for these groups. It is then the system manager's responsibility to add entries for these groups to the password table and recommend group parameter settings. The system manager, however, is the only user authorized to create permanent groups. This is done with the CREATE command, which is described in the Rocket Model 204 System Manager's Guide.
Opening permanent file groups
If passwords are required for a permanent file group, only users who know one of the group passwords can open the group. As with file security, the group password determines the types of operations that the user is authorized to perform on the group that is being opened. The privileges associated with the password determine the extent of these operations. Group security operates differently under the Subsystem Management facility. See Subsystem security.
Opening temporary file groups
Opening a temporary group is functionally equivalent to opening a series of files. Only the user who creates a temporary group can open it. To open a temporary group, the user must be able to open each file in the group individually.
Group file privileges
The types of permanent groups are:
- Public
- Semipublic
- Private
These types are the same as described in File manager's responsibilities.
When a user opens a semipublic or private group, Model 204 requests that the user enter the password. When the group is opened, the user is granted either the privileges associated with the group password or the default privileges for the group, depending on the password supplied. Default privileges are also supplied when a public group is opened.
Group passwords and privileges
A permanent group can have several passwords defined for it. Like a file password, a group password can have up to eight characters and cannot contain blanks, commas, or colons. Each password can have a different set of privileges associated with it. These privileges determine what operations can be performed on the group by the user who opens the group with that password. Privileges are expressed as two hexadecimal bytes, as discussed in PRIVDEF parameter and group privileges.
PRIVDEF parameter and group privileges
If a value for PRIVDEF and a PUBLIC, SEMIPUB, or PRIVATE specification is not specified at the time that the group is created, the group is assumed to be a PUBLIC group that has default privileges of X'3FFF'. The PRIVDEF parameter, which summarizes the default privileges for a group, provides all the privileges shown for files, plus the two group privileges summarized here. These privileges are identical to the privileges that can be specified for an individual group password in the password table. The X'8000' privilege has no meaning for groups, although it can be important for individual references to member files.
| Bit | User can... |
|---|---|
| X'0004' | Update data through procedures from the procedure file. |
| X'0002' | Retrieve data through procedures from the procedure file. |
When a group is created, one of its member files can be designated as the procedure file. This is the file in which procedures for the group are stored and from which procedures are retrieved or deleted.
In a group context, internal means that a file is a member of the group, while external means that a file is not a member of the group.
Determining file and group privileges
When a command or a User Language statement refers to a file or group, Model 204 checks the file and group privileges to ensure that the operation is allowed. Model 204 must determine whether a file has been opened as an individual file, as a member of a permanent or temporary group, or as both.
The privileges associated with individual files and groups can be granted and combined in different ways, depending upon the reference context, as shown in the following table.
| Referring to... | User's privileges are... |
|---|---|
| Individual file | Same as those granted by Model 204 when the file was opened. These privileges are associated with the specified file password or, if no password is required or is incorrectly specified, the default file privileges. |
| Temporary or ad hoc group | Intersection of the individual privileges associated with the files that make up the group. Model 204 compares the privileges of all of the member files; only privileges that are common to every file are granted. |
| Permanent group | Same as those granted by Model 204 when the group is opened. These are the privileges associated with the specified group password or, if no password is required or is incorrectly specified, the default group privileges. |
|
Member of a permanent group (not opened individually) |
Those granted for the group. If the file is opened individually, its privileges remain those granted when the file was individually opened. |
| Two permanent groups (not opened as individual files) | Union of the privileges associated with the groups. Model 204 combines the privileges of all open groups of which the file is a member. Any privileges specified for any of the groups are granted. |
| File open as both an individual and a group | Privileges associated with the file, not the group. No open group has an effect on the file privileges. |
Record security
In addition to protecting an entire file or group from unauthorized access, you can also protect individual records in a file. When record security is in effect for a particular Model 204 file, each user can be allowed to retrieve and update only records stored in the file with that user's ID or records that other users have agreed to share. The user does not know that any other records exist.
Record security can be in effect for one or more of the files in a group, but not for the group as a whole. Access to a single record depends on only the record security field defined for the record's file.
Record security and login security
Model 204 record security can be considered as an extension to login security and cannot be used unless the login security feature is in effect at an installation. Login security is primarily the system manager's responsibility and is discussed in detail in the Rocket Model 204 System Manager's Guide.
File manager responsibilities
Record security usually is the responsibility of the file manager. To initiate record security, set the OPENCTL parameter in the CREATE command to indicate that record security is in effect and describe the special record security field in the INITIALIZE command, which is discussed in "Initializing record security files". You can turn off record security by using the appropriate OPENCTL setting with the RESET command, but it cannot be turned on by RESET. The file must be defined to have record security through the CREATE command.
Setting record security for remote users
If your site has the Parallel Query Option/204 product, you can control access to remote files with record security using the PQOSYS CCAIN system parameter. If set, PQOSYS creates a special record security key for remote users. For more information about PQOSYS, see the Parallel Query Option/204 User's Guide or the Rocket Model 204 Parameter and Command Reference.
Storing and retrieving records
After a file has been initialized with a record security key, each record stored in the file with a User Language STORE RECORD statement automatically has a record security field added to it, whose value is equal to the current user's login user ID.
Storing record security fields through File Load or the Host Language Interface
For records stored with a Host Language Interface IFBREC or IFSTOR function or by a file load program, a record security field must be added explicitly, along with other fields, when the record is created. For example, the following file load statement adds a record security field:
LDC RECSEC=DARCY=
Refer to the File Load chapter for information about the File Load utility.
Only records that have a record security field whose value is equal to the current user's login user ID are retrieved by a User Language FIND statement or Host Language Interface calls that perform a find function. If the FILE LOAD statement shown here is executed, for example, only a user logged in under the name DARCY can retrieve these records.
Allowing multiple access
To share a record with another user, either you or the user can add an explicit occurrence of the record security field with a value equal to the second user's login user ID. If the second user has update privileges, that user can delete the first value of the record security field, thus making the record accessible only through the second user's user ID.
Multiple access in 1NF files
To allow access to record security fields in 1NF files, you must define the record security field as INVISIBLE and REPEATABLE.
Overriding record security
Occasionally, it may be necessary to override the Model 204 record security scheme. To override record security, you must have the appropriate record security override privileges at login time: the X'04' bit must be set. When the file is opened, the X'4000' bit must be set.
If both privileges have been granted, you can retrieve all records, regardless of the record security key value associated with them. However, if you store records from User Language at this time, they still have the record security field with the value of your login ID added to them automatically.
If record security was specified for a file in a permanent group, you can override record security for the file if login and group privileges (X'4000') allow it.
For further information regarding login security bit settings, see the Rocket Model 204 System Manager's Guide.
Field-level security
Field-level security (FLS) provides an additional level of protection for a user's data by controlling access to the individual fields of a Model 204 file. It involves a comparison of the user's predetermined numeric access level for a field with the field's own predetermined level, for each of four types of access. Field-level security specifications are put into effect only if access to a data record has been allowed by previous file-level and record-level security checks. The following paragraphs describe in detail how field-level security operates.
In addition to field-level access for each field, each file has a default access level (that is, all fields within the file are automatically assigned access levels).
The following parameters determine the default field access:
| This parameter | Provides this default field access... |
|---|---|
| SELLVL | SELECT |
| READLVL | READ |
| UPDTLVL | UPDATE |
| ADDLVL | ADD |
Like PRIVDEF, these parameters can be set when a file is created, or they can be reset later. If not explicitly specified, all of these parameters are set to zero, which allows a user to access only unsecured fields (that is, fields with access levels of 0). The same four parameters can be set for a permanent group when it is created by the system manager.
File manager responsibilities
The file manager is responsible for determining the desired field-level security scheme and for assigning security levels to fields that are to be protected. The DEFINE command described in Defining fields describes the LEVEL option, which allows you to indicate the security level for the field.
For example, if the following command is issued, only users who have access levels of 70 or greater are allowed to access the PERFORM field, which might contain an employee's performance evaluation code:
DEFINE FIELD PERFORM WITH LEVEL 70
Types of field access
By using the Model 204 field-level security scheme, you can protect particularly sensitive data fields from unauthorized access. A field can be accessed in several different ways.
Field-level security features limits access to a field to any combination of the following access types:
| This access type | Allows you to... |
|---|---|
| SELECT | Use the field in a User Language FIND statement or in an IFFIND call. |
| READ | Examine the value of a field, for example, in a User Language PRINT or assignment statement or an IFGET call. |
| UPDATE |
Change the value of a previously stored occurrence of a field. This type of access can be granted without a corresponding READ access, which precludes updates of the form shown below: CHANGE field_name = value TO value |
| ADD |
Add new occurrences of a field, including those added by a STORE RECORD statement. This type of access allows data entry clerks or other personnel to add new field occurrences or records without being able to change existing occurrences, or possibly even to examine them. This type of access can also provide a user with the ability to add occurrences of the record security field without altering existing occurrences. |
Field-level security controls only explicit field references. Implicit references, such as retrieving a record security field with a FIND statement or adding a record security key value with STORE RECORD, are not controlled.
Field levels
Every field definition can have a security level associated with it. Security levels are numbered from 0 to 255. 0 implies no security for the field; 255 implies the highest security.
Field-level security and field ordering
In the Model 204 field-level security scheme, fields can be assigned security levels in a hierarchical fashion. The fields can be ordered in view of the sensitivity of the data that they contain. An example of such an ordering is shown in Field levels, the fields being listed in order of increasing sensitivity.
| Field | FLS READ level |
|---|---|
| Last name | 0 |
| First name | 0 |
| Employee number | 0 |
| City | 10 |
| State | 10 |
| Zip code | 10 |
| Street address | 20 |
| Position | 30 |
| Telephone number | 40 |
| Salary | 60 |
| Performance evaluation | 70 |
In Field levels, performance evaluation is considered to be the most sensitive field in the record, followed by salary, and so on. Last name, first name, and employee number have not been assigned field-level security numbers. However, file, record, and procedure security features still can be used to control access to those fields.
User levels
Each user has four field-level security access levels associated with each file and group opened. These correspond to the four field access levels defined previously: SELECT, READ, UPDATE, and ADD. User levels also range from 0 to 255.
When a user attempts to access a field in a particular way, Model 204 compares the user's access level with the level assigned for the field. If the user's level for the desired type of access, for example, READ, is greater than or equal to the field's FLS level, the particular type of field access is allowed.
User-level security example
For example, a user who has a READ level of 30 is permitted to print any field that has a READ level between 0 and 30, but cannot print a field that has a higher READ level. Thus, when using the file described above, a user who has a READ level of 30 can print an employee's position (and all fields that have lower FLS fields), but not the employee's telephone number, salary, or performance evaluation. An example of a possible set of access levels at an installation is shown in Table 16-2.
| Employee category | SELECT | READ | UPDATE | ADD |
|---|---|---|---|---|
| Data entry clerks | 0 | 0 | 0 | 60 |
| Personnel department clerks | 50 | 50 | 40 | 0 |
| Personnel department supervisor | 70 | 70 | 70 | 0 |
| Other employees (for example, telephone operators) | 0 | 10 | 0 | 0 |
| Employee supervisor | 0 | 70 | 0 | 70 |
The motivations for these assignments easily can be understood in relation to the sample file. Only data entry clerks can add employee records; only supervisors can add performance evaluations; only personnel department supervisors can update salaries, and so on.
Referring to or displaying fields
When a user's access levels are lower than permitted for the level of a particular field, a reference to the field is treated as a reference to a nonexistent field. Furthermore, the names of such fields are excluded from the output of the DISPLAY FIELD ALL command. Thus, when using the file shown in User levels, only personnel and employee supervisors know that a performance evaluation field even exists in the file. The field is never visible to other users.
Limiting access to fields
Access to records for particular employees can be controlled in another way. Employee supervisors usually are given a password that allows them to read or add any field in the file. However, procedure- or record-level security can be used to restrict supervisors' access to only the records of their employees.
Determining user access levels
The access levels assigned for a user are determined when the user opens a file or a group using the OPEN command described in the Model 204 Parameter and Command Reference, or using the OPEN statement described in the Rocket Model 204 User Language Manual. Access level assignments are made for various types of files or groups as follows:
- If a file or a permanent group is public or semipublic and an incorrect password is specified in the OPEN, the user's four access levels are taken from the file or group defaults described in Procedure security.
- If a private or semipublic file or group is opened with a valid password, the user's four access levels are the same as those associated with the password.
- If a temporary or ad hoc group is opened, all the member files are opened separately as individual files. Opening these individual files establishes a set of four access levels for each member file.
Access levels for temporary or ad hoc groups
The four access levels for a temporary or ad hoc group are formed by taking the minimum of each access level across all the member files. Suppose that FILEA and FILEB have the access levels shown in the following table.
| File | SELECT | READ | UPDATE | ADD |
|---|---|---|---|---|
| FILEA | 30 | 40 | 10 | 0 |
| FILEB | 40 | 30 | 0 | 10 |
If a temporary group named FILES, consisting of FILEA and FILEB, is opened, the group is assigned the access levels:
| Group | SELECT | READ | UPDATE | ADD |
|---|---|---|---|---|
| FILES | 30 | 30 | 0 | 0 |
This is equivalent to the comparison of file privileges that occurs when opening a temporary or ad hoc group; see Group security.
Examples
The following examples show how your user access levels for a file can change as the reference context changes. In the examples, the four user-access levels, SELECT, READ, UPDATE, and ADD, are represented by their first letters.
A field reference occurs in single file context, and the file is opened as a single file:
S R U A OPEN FILE FILEA 100 100 10 20 BEGIN FPC NAME=JONES END
The four access levels used in checking field references (100, 100, 10, 20) are those assigned when FILEA was opened as a single file.
A field reference occurs in group context:
S R U A OPEN FILE GROUPA 50 75 20 0 BEGIN FPC NAME=JONES END
The four access levels used for checking field references in any file of the group (50, 75, 20, 0) are the four assigned when the group was opened. All the files in a group receive the same four access levels.
A field reference occurs in single file context, but the file was opened only as a member of one or more permanent groups. FILEA is a member of the two groups, GROUPA and GROUPB:
S R U A CLOSE FILE FILEA OPEN GROUP GROUPA 50 75 20 0 OPEN GROUP GROUPB 50 50 0 100 BEGIN IN FILEA FPC NAME=JONES END
The four access levels used in checking field references (50, 75, 20, 100) are formed by taking the maximum level defined for the file by every group containing the file that the user has opened.
Procedure security
Model 204 procedure security limits access to a file's procedures in the following ways:
- By allowing you to specify user privileges that control the type of functions that can be performed on the procedures within a file, for example, to display, define, or delete the procedure.
- By limiting access to a procedure to only a particular class of users. This is done by assigning a procedure class number to the procedure that is being secured and a user class to the users allowed to manipulate the procedures.
These security features are discussed in greater detail in the following sections. In addition, File security and Group security discuss the privileges that enable users to access the data in a file or group through procedures.
Accessing procedures
At the time a file or group is opened, particular privileges are established that concern the text of the procedures stored in the file or group. These privileges, or access rights, enable a user to manipulate a procedure in any of the following ways:
- Use the procedure, for example, by specifying it in an INCLUDE command.
- Display and copy the procedure. This includes echoing the procedure and using the EDIT command to display or copy it.
- Change the procedure, usually with the Editor.
- Define a new procedure in the file with the PROCEDURE command or the Editor.
- Delete a procedure by means of the DELETE command.
The basic procedure functions and commands are discussed in detail in the Rocket Model 204 User Language Manual.
Securing procedures
The privileges established for procedure access discussed in PRIVDEF parameter and file privileges are used to limit the way in which the procedures associated with a file or group can be accessed. Model 204 provides an additional facility that allows particular procedures to be secured and thus protected from unauthorized access.
User and procedure classes
You can limit user access to procedures by assigning user classes that have access to procedures in a particular procedure class.
User and procedure classes are usually put in place as part of the security scheme for a file or group. Although every user and procedure could have a distinct class number (UCLASS and PCLASS), this approach is too complex and cumbersome for most installations. Thus, sets of procedures and users more often are handled together.
User classes (UCLASS)
Examples of typical user classes are:
- All employees in a department
- All managers, regardless of department
- All data entry personnel
Procedure classes (PCLASS)
Examples of typical procedure classes include procedures that:
- Display salary data
- Update personnel records
- Perform general utility operations
- Access sensitive fields in files
Procedure classes and user classes are arbitrary numbers that range from 1 to 255. Their only significance is in their relationship to each other. The numbers are assigned as described in User and procedure classes.
When a user opens a file or group, the user is given the privileges and user class determined by the OPEN:
- If the file or group is opened with a password, the user class is obtained from the password table, where it is stored with the privilege bytes and field-level security levels for the password.
The user class normally is provided by the file manager and entered into the password table by the system manager, as discussed in the Rocket Model 204 System Manager's Guide.
- If the file or group is opened without a password, the user is granted default privileges and a default user class. This default user class is the value of the PRCLDEF system parameter, which has a default value of zero and can be set by the file manager.
Relationship between user and procedure classes
An access control table (ACT) stored in each file assigns to particular user classes the access rights to particular procedure classes. These mappings from user class to procedure class in the ACT are created using the SECURE command described in SECURE command, definition format.
The user class established for a group applies to all its member files. If a file is opened only as part of a permanent group, any reference to a secured procedure compares the user class specified for the group against the procedure's class to determine the available access rights.
Example
The association of user classes and procedure classes can be explained best by an example:
Suppose that a user whose user class is 8 includes a procedure named CENTEST, which has a procedure class of 20. Model 204 must determine whether users of class 8 are allowed to include procedures of class 20.
If Model 204 checks the ACT in the file in which CENTEST is defined and finds that an INCLUDE is permitted, the procedure is included.
If, however, INCLUDE is not permitted for users of class 8, the INCLUDE does not take place and an error message is issued.
This mapping of user and procedure classes is discussed in greater detail in the sections that follow.
Assigning procedure classes
A procedure class can be specified for a procedure by the file manager or by an individual user. The class can be assigned:
- By the user when defining the procedure with the PROCEDURE command
- By the file manager when securing the procedure with the SECURE command
User-defined procedure classes
When defining a procedure, the user can specify a procedure class number in the following format:
Syntax
PROCEDURE name PCLASS=n
where:
n is any number in the range 1 through 255.
A user's access rights to procedures are checked first at the file level and then at the procedure level. Thus, if the user is to be allowed to change a secured procedure, the user must have procedure update file privileges, and the appropriate entry must have been made in the ACT.
File manager-defined procedure classes
File manager-defined procedure classes are discussed in the following sections, in context of the commands that the file manager uses for this purpose.
SECURE command, definition format
If you have appropriate file manager privileges, you can use the SECURE command in the following form to:
- Secure both files and procedures
- Define privileges for procedures that already have been secured
- Make entries in the access control table
The format is:
Syntax
SECURE [PROCEDURE] NAME=procname [,procname ...] PCLASS=pclass
where:
procname is the name of an existing procedure to be secured.
pclass is the procedure class number to assign to the procedure(s); the number must be in the range 1 to 255.
The SECURE command must be issued in file context, that is, the current default must be a file, not a group.
Example
The following example is a SECURE command used to secure a procedure:
SECURE PROCEDURE NAME = PAY PCLASS = 7
After this command is issued, the procedure PAY is secured with the procedure class number 7. An entry for PCLASS=7 is made in the procedure dictionary. If PAY is currently secured, its old procedure class is changed to the new class.
SECURE command, mapping format
The SECURE command lets you map particular access privileges and user classes to particular procedure classes. This command creates entries in the access control table. Issue the following form of the command:
Syntax
SECURE [PROCEDURE] ACCESS = {ALL | (access [,access...]) | NONE} UCLASS = {ALL | (uclass [,uclass...])} PCLASS = {ALL | (pclass [,pclass...])}
where:
access is a particular privilege associated with the procedures in the procedure class. It can be one of the following:
| Privilege | Users can... |
|---|---|
| USE | Include procedures. |
| COPY | Display and edit (copy only) procedures. |
| CHANGE | Edit procedures. |
| DEFINE | Create new procedures (PROCEDURE and EDIT). |
| DELETE | Delete procedures. |
uclass is the user class number whose users have access to the procedures in PCLASS; the number must be in the range 1 to 255. Parentheses are optional in the uclass definition.
pclass is the procedure class number to which users in UCLASS have access; the number must be in the range 1 to 255. Parentheses are optional in the pclass definition.
Example
In the following example, only users in the Payroll Department (user class 90) are allowed to use procedures that manipulate salary fields in a file (procedure class 20 and 30):
SECURE PROC ACCESS = (USE) UCLASS = 90 PCLASS = 20,30
The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the Model 204 Parameter and Command Reference.
To complete procedure security implementation, the system manager updates the password table using the LOGCTL command to assign user classes to the appropriate passwords.
The following list is a summary of Model 204 procedure or procedure-related commands that require particular privileges. All these commands are described in the Model 204 Parameter and Command Reference.
| Command | Required privileges | |
|---|---|---|
| INCLUDE | USE | |
| EDIT | COPY | |
| DISPLAY | COPY (to display text) | |
| DELETE | DELETE | |
| ASSIGN | CHANGE | |
| DEASSIGN | CHANGE | |
| RENAME | CHANGE | |
| Command | New procedure | Old procedure |
| PROCEDURE | DEFINE | CHANGE |
|
EDIT commands: GO END |
DEFINE, USE* DEFINE |
CHANGE, USE* CHANGE |
| *COPY privileges are required in addition to USE to echo text lines of a procedure to a journal. | ||
Displaying user and procedure classes
The SECURE command constructs entries in the access control table for any user classes specified in the UCLASS clause.
Note: It is important to display procedure security and save it before reorganizing a file, so that you can reestablish the same security. You might have to upgrade your file manager privileges to include COPY, which is not part of the default privileges of a file manager.
To determine a user's access rights for various procedure classes, issue the following form of the DISPLAY command:
Syntax
DISPLAY [PROCEDURE (PRIVILEGES [,NOUSE]) [ALL | UCLASS = uclass[,uclass...]]
where:
ALL displays information for all user classes.
uclass displays information only for the specified classes.
If neither is specified, your current class and privileges are displayed.
Privileges are displayed in the following format:
UCLASS=u PCLASS=pc,X'nn' . . . PCLASS=pc,X'nn'
where:
u is the user class.
pc is a procedure class defined for that user class.
nn is a privilege byte constructed from combinations of the following bit settings:
| Bit | Privilege |
|---|---|
| X'80' | USE |
| X'40' | COPY |
| X'20' | CHANGE |
| X'10' | DEFINE |
| X'08' | DELETE |
If NOUSE is specified, information is displayed at your terminal even if a USE command preceded the DISPLAY command. The device specified by the USE command is not used but is left open.
See the discussion of other DISPLAY command capabilities in Overview.
Sample security scheme
A simplified example of a security scheme at an installation is presented in this section. At this installation, the following access rules are established:
- Most users are allowed to include all secured procedures.
- Only programmers in the data processing department are allowed to define procedures. However, they cannot use them. These programmers can have user classes 8 or 9.
- Only users in the payroll department are allowed to use procedures that manipulate salary fields in the file. Payroll users are assigned class 90, and the payroll procedures are in procedure classes 20 and 30.
- Other users are assigned user classes 25, 30, or 31.
- Other procedures are in procedure classes 40, 50, 60, or 70.
Sample SECURE commands
To create the security scheme in this example, issue the following commands:
SECURE PROC ACCESS=(CHANGE,DEFINE,DELETE,COPY) UCLASS=8,9 PCLASS=20,30,40,50,60,70 SECURE PROC ACCESS=(USE) UCLASS=90 PCLASS=20,30 SECURE PROC ACCESS=(USE) UCLASS=25,30,31,90 - PCLASS=40,50,60,70
Importance of SECURE command order
In this example, the order of the SECURE commands is unimportant. However, the order becomes significant when a UCLASS=ALL or PCLASS=ALL clause is included in the command. UCLASS=ALL affects only user classes already mentioned in the ACT. This might be completely different from the list of user classes that actually can be assigned to users from the password table or default file or group settings.
When PCLASS=ALL is included in the command, no new entries are added to the ACT. Instead, for each user class in the UCLASS list, access rights for each procedure class already mentioned for that user are replaced by the new ACCESS rights. Again, the classes affected in the ACT may be completely different from those actually used for secured procedures in the file.
Changing and adding access privileges
Suppose, in this sample security, that the payroll users now need to be able to display all the procedures that they use. Also, suppose that a new set of procedures (of class 15) is developed that all users (including the programmers) can include. The following commands are issued in the order shown to modify the ACT entries already built:
SECURE PROC ACCESS=(USE) UCLASS=ALL PCLASS=15 SECURE PROC ACCESS=(USE,COPY) UCLASS=90 PCLASS=ALL
If these commands are reversed, the payroll users cannot display members of the new class of procedures.
Removing procedure security for procedures or user classes
To remove the procedure access defined for user class/procedure class pairs, use the DESECURE command:
- Remove the security for the procedure involved.
- Delete the procedure class number assigned to the procedure in the procedure dictionary by issuing the form of the DESECURE command immediately below.
Note
If you do not do this, no one can access the procedure, even though the entry might have been removed from the ACT (see the second form of DESECURE below).
Only file managers can issue the DESECURE command and it must be issued in file context (that is, the current default must be a file, not a group).
The format of the DESECURE command is:
Syntax
DESECURE PROCEDURE {ALL | NAME=(procname[,procname...])}
where:
procname is the name of an existing secured procedure.
To remove particular access privileges for particular procedure classes, use the following form of the DESECURE command to delete entries from the ACT. You must specify either UCLASS or PCLASS, or both.
The format is:
Syntax
DESECURE PROCEDURE {[UCLASS= {ALL | (uclass[,uclass...])}] | [PCLASS= {ALL | (pclass[,pclass...])}]}
where:
- uclass is the number of an existing user class whose users have access to the procedure in pclass; the number must be in the range 1-255. If only UCLASS is specified, all references to the specified user classes are removed from the ACT.
Parentheses are optional with uclass.
- pclass is the number of an existing procedure class to which users in uclass have access; the number must be in the range 1-255. If only pclass is specified, all references to the specified procedure classes are removed from the ACT.
Parentheses are optional with pclass.
Desecuring both UCLASS and PCLASS
If both UCLASS and PCLASS are specified, the entries for all combinations of the specified user and procedure class pairs are removed from the ACT. For example:
DESECURE PROC UCLASS=8,9 PCLASS=1,2,3
removes access entries for:
UCLASS 8 and PCLASS 1 UCLASS 8 and PCLASS 2 UCLASS 8 and PCLASS 3 UCLASS 9 and PCLASS 1 UCLASS 9 and PCLASS 2 UCLASS 9 and PCLASS 3
System manager responsibilities
The final step in the desecuring process is to have the system manager remove the password(s) with associated uclasses from the password table. If they are not removed, you must remember not to use them when opening the file.
Privileges required
You must have file-level privileges of at least X'A000' (file manager and ad hoc data update) to issue SECURE and DESECURE commands. In this case, you actually need update but not retrieve privileges. (Refer to File security for a discussion of these privileges.)
File and group references
When an explicit reference is made to a file with an IN clause and that file is opened only as a member of one or more permanent groups, the file-level privileges to be checked must be obtained from the group privileges, as defined for every group of which the file is a member. If any group's privileges allow the access in question, then the operation proceeds.
If the access is to a secured procedure, for every group in which the file is opened and the access is allowed by the group privileges, the user's user class in that group is used to determine privileges for that procedure's class. If any group's user class has the privilege, the operation proceeds.
See the discussion of reference context in the example on Determining user access levels and the Rocket Model 204 User Language Manual for more information.
Subsystem security
When a user enters a subsystem, Model 204 opens and determines privileges for all subsystem files and groups for that user. The files that are opened and the privileges that are assigned are based on a combination of the user's subsystem user class and the subsystem's status, both specified by the system manager in the subsystem definition.
The system manager assigns a user to a subsystem user class by entering the user's Model 204 login user ID in the appropriate subsystem user class. Whenever the user invokes the subsystem, the user is assigned the subsystem command privileges and the file and group privileges of that subsystem user class.
The system manager controls access to the subsystem through the subsystem status: public, semipublic, or private. The status determines which user classes can enter a particular subsystem and whether or not users without a user class assignment are permitted entry.
For more information about subsystems, see the Subsystem Management facility description in the Rocket Model 204 System Manager's Guide.
Terminal security
Model 204 terminal security allows access to certain login user IDs, files, or groups to be restricted to users at certain terminals. For example, you might want a particular MEDICAL file to be accessible only through terminals located physically in doctors' offices.
The terminal security feature allows a list of terminal numbers to be associated with each login, file, or group password. A terminal number is determined during Model 204 initialization by the order of the user parameter lines and the way in which they are assigned to specific telecommunications unit numbers in the JCL.
The batch user (User 0) is considered to be terminal 0 (zero). A user at a particular terminal whose number is n can log in to a specific user ID or open a specific file or group only if the terminal number, n, is in the terminal list associated with the password for that user ID, file, or group. If it is not, Model 204 responds as though the user had entered an invalid password.
Terminal security is generally used with only hard-wired terminals, that is, terminals on leased lines. If an installation has dialup terminals, the terminal can be connected to a number of similar telecommunications units and user parameter lines. In this case, although the location of the terminal can be fixed, its terminal number can change evep>The entries in the ACT do not take effect for users that have the file open when the SECURE command is issued until they reopen the file. This includes the user who issues the command. The complete syntax and description of the SECURE command is located in the ry time it is dialed up.
By controlling the assignment of terminal numbers to physical terminals, the system manager determines the appropriate terminal security scheme. You provide assistance in limiting file and group access through file passwords and privileges, and group passwords and privileges.