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 Storing security information (CCASTAT).
• Rocket Software has add-on interfaces between Model 204 and a number of security products. These security interfaces are described in the Security interfaces pages.
• SSL/TLS security features for Janus products are described in Janus Network Security.

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 topic.

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 Login security 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.

Multi-factor Authentication - MFA

Support for logon with Multi-factor authentication (MFA) is also provided with no updates or parameter changes required to Model 204. MFA does require that one of the three security interfaces, listed below, be linked into the Model 204 nucleus. Once a userid is provisioned under MFA, the user acquires a token from a client, e.g. IBM Security Verify, installed on the user's mobile device. That token is then concatenated, with a password or passphrase, to logon to Model 204. For example: token:password or token:passphrase, where colon (:) is the concatenating character. That string is passed, unmodified, to the security interface for verification.

• ACF2
• RACF
• TopSecret

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 Password table data set.

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: If the user enters a valid password, the user is given the privileges associated with that password. If the user does not know the password or enters an incorrect password, the file is still opened but the user is granted the default file privileges associated with the file.
Private	Prompts the user to enter a valid password: If the user enters a valid password, the file is opened and the user is granted the privileges associated with that password. If the user does not know the password or enters an invalid password, the file is not opened.

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 OPEN FILE command and also see OPEN statement and OPENC statement.

Creating files with file security

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 PQO: Remote files and scattered groups.

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:

1. Have the system manager create a permanent private group that contains the locked file.
2. Have the system manager add a group password (and tell you that password) to the password table, CCASTAT, with the privileges X'BFFF'.
3. 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:

SECURE

Desecuring a file

To desecure a previously secured file, issue the command:

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, as described in Creating file groups.

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 SOUL 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 it is discussed in detail in Login security.

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 Record security for remote users: the PQOSYS parameter.

Storing and retrieving records

After a file has been initialized with a record security key, each record stored in the file with a SOUL 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 File Load utility 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 SOUL 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 File security.

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 LEVEL option 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 SOUL FIND statement or in an IFFIND call.
READ	Examine the value of a field, for example, in a SOUL 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 fieldname = 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-level ordering example

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 below:

User access levels example

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 FILE command, OPEN PERM GROUP command, or OPEN TEMP GROUP command or using the OPEN statement. 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.

For information about the basic procedure functions, see the $Prc* and $Proc* functions in List of $functions; and for information about procedure related commands, see Category:Commands.

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 Password table maintenance.

• 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:

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:

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:

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. See SECURE PROCEDURE ACCESS command for the complete syntax and description of the SECURE command.

To complete procedure security implementation, the system manager updates the password table using the LOGCTL command to assign user classes to the appropriate passwords.

Procedure-related commands and required privileges

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.

Privileges for procedure or procedure-related commands

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:

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:

1. Remove the security for the procedure involved.
2. 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:

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:

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 see Files, groups, and reference context 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 System requirements for Application Subsystems.

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 every time it is dialed up.

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.