05 es2m expo internal security maintenance
ES2M - EXPO Internal Security Maintenance
| Program ID: | ES2MP01, ES2MP02 |
|---|---|
| Mapset: | ES2MMS1 |
| I/O Files: | Internal Security File (ES2SECR) |
The MP01 program enables the QCEW supervisor, or another person designated as an EXPO security administrator, to control the data manipulation authorization of EXPO and EARS system users. Persons involved in QCEW data maintenance will need to have update capabilities. Users on the periphery, such as CES, Contributions, and other persons who need QCEW data only for verification or research, generally only need inquiry-level access. The ES2M transaction provides authorization codes for each person accessing the system, identifying their level of access. Administrator (“A”) and Manager (“M”) access levels are almost synonymous. The differences will be described shortly.
The State identification is found on top of the screen. This is necessary for Service Center States, since many States share the same computer system in Florida. States outside the Service Center use standardized file identifications (such as “ES2LKUP” for the Lookup File). Service Center States must have all of their files on the same computer, so they are distinguished by their State postal abbreviation in positions 2 and 3 of the file ID. The testing state of “97”, shown above, is placed into the 2nd and 3rd positions of the file ID’s, like the Lookup File – “E97LKUP”.
As the title indicates, this security system is internal to EXPO. It doesn't supersede or countermand system-wide security settings in packages such as RACF, ACF2, and TOP SECRET. In fact, this assumes that other security systems are already allowing those users who need any access into the system to get into any CICS transaction or file they require. On the other hand, internal security measures can curtail privileges that were granted by higher-level control systems. Essentially, it is a two-door situation: the outer door (external RACF, etc., controls) enables a user initially to access the system. The inner door (internal security) determines what level of access to grant the user once they are into the system itself. Both doors must be open to allow file maintenance access to the user, but each door carries its limitations.
If the RACF or other external security controls were to grant full, unlimited access to the EXPO system for a user, that person could still be limited to inquiry-only access (the initial default) in the system if EXPO doesn’t recognize the user’s CICS logon ID as an authorized user 10. Similarly, if RACF denies access to a user, that person will not even be able to get to the first menu screen in EXPO, though he or she may be flagged as an EXPO system administrator.
For the Service Center, there is only one Security File shared by all production states (another Security File exists for Beta-test states). However, only those users in your own State are visible to you on the screen; all others are filtered out of the display. Persons who do not have an ID associated with your State cannot access your data, nor can you access another State’s data.
This system covers two levels of authorization. The first is called the default security level, which is identified by a letter in the left half of the screen. A value of “I” (for Inquiry) is the lowest access level, indicating that the person can perform inquiries on most of the system files, but is not authorized to add new records or change or delete records currently on file. This level would be assigned to users outside the QCEW unit – people who need to look at, but not modify, QCEW data. The “U” (for Update) access mode is the most common, covering update authorization. This level would include most QCEW-unit clerks and analysts. The “M” (for Manager) and “A” (for Administrator) access levels are essentially the same, but they will view Micro Data (e.g., from the ES2C screen) differently. Like the “U” access people, the “M” and “A” people have update authority. However, they can get into areas that others cannot touch.
Only the “M” and “A” people can enter this ES2M screen, since they are at the highest level of authorization within the EXPO/EARS system. From ES2M, a manager/administrator may add new log-on ID’s into the system, alter authorization levels, or delete individuals from the list who have left the agency. The only visible difference between an “M” and an “A” security level is the appearance of data on ES2C. An “A” person will see all fields as updateable (showing in green), even if all of the locks have already been set in the ES2I screen. An “M” person will show the locked fields still in turquoise and will not be able to alter any of the locked data. The primary reason many administrators prefer to spend most of their time in “M” status is as a safety precaution. Having all of the data laid open gives more opportunity for a missed keystroke to be processed into the data.
The one time when “A” access is needed is during the last-minute clean-up process just before the EQUI is shipped. If the final edit reveals a handful of establishments that require minor adjustments – but the file is locked – the “A” access can permit one person to bypass security locks just long enough to “surgically” correct the remaining problems, without unlocking the files so that other mistakes could be keyed by a person with “U” access. An Administrator/Manager may change his/her status at any time.
If a user is allowed in by the external security measures, but is not found in the Internal Security table, a default inquiry-level access would be granted (for non-Service Center States). Because of this, there are only two reasons for which a person with inquiry access would need to be added to the system. The first (outlined by the footnote on the previous page) is that a State operating in the Service Center environment, or converting to that environment, requires all users to be defined as an additional security measure. The only reason for a non-Service Center State to require addition of an inquiry-only user would be for a person needing to peruse one or more of the more sensitive screens (ES2L or ES2N), as outlined below.
The second type of security authorization is for specific CICS transactions, those that are by nature in need of superior data integrity. These include the micro data locking transaction (ES2I), the Lookup File maintenance (ES2L), and the on-line entry of batch job parameters (ES2N). These are listed individually for each user line. The presence of the corresponding letter from the transaction ID in the specific column indicates that the user is allowed to access one of these more sensitive transactions. However, these screens carry additional update authorization precautions. Only an administrator may alter the lock settings in ES2I; only manager or administrator level access is sufficient to alter Lookup data in ES2L and ES2N. For those persons with insufficient authorization, it will still not be possible to update any data in these screens.
To add a new user, the security administrator/manager needs to press the F5 key. This will clear the table from the screen to allow the new user’s data to be entered in the top line of the table. Enter the CICS logon ID of the new user into the User-ID field. Then type in the user’s name in the next field; this will be followed by the default security level (“A”, “I”, “M”, or “U”), and any transaction access letters needed by the individual. Pressing the Enter key will then add the new record to the file.
Deletion of an obsolete user is also quite simple. Locate the user’s logon identification or name in the user list. Then tab to that person’s name field and type ‘*D’ to delete the entry. Multiple user records can be deleted simultaneously by flagging each obsolete user record with the ‘*D’ code, tabbing to the next record to mark. When all user entries to be deleted have been marked, pressing the Enter key will enact all flagged deletions. The authorization level of the person to be removed is immaterial to the action; therefore, even a person with administrator-level access can be removed. It is recommended that only a limited number of persons be set up with administrator-level access in each State. Only those who truly need to update user access data should be granted administrator-level authorization.
User security records are stored on the Internal Security File; the record layout of this file is found in the File Record Layouts documentation (as ES2SECR). Once the access level of a user is established, CICS transactions can check the user’s authority (and State association, for the Service Center), via the ES2MP02 program. This program acts as a common subroutine throughout CICS, calling up the current user’s security information and returning the data in a highly compressed equivalent form. The use of a Service Center switch and the associated State abbreviation allows the calling program to identify which files to access.
Besides verifying security access for the user, the MP02 program also tracks usage statistics for the individual. It stores the latest access date and time, current screen ID, and the number of CICS screen displays that have been enacted by the individual. These values are stored in the user’s internal security record, but are not accessed or displayed anywhere. They are intended to assist in tracking down CICS problems by discovering who last accessed a defective program to find out what triggered the problem in the first place. It may also serve as a check for those persons who have left the QCEW system and can be removed from the Security File.
Certain States may choose to set up their security measures based on terminal ID rather than CICS logon ID. The usual reason for such a decision is that some QCEW units assign a single ID to apply to several persons. Assigning security based upon the terminal ID distinguishes among members of this group according to where each person sits. When a user ID is not found in the Internal Security File, the terminal ID is checked to identify this alternate definition.
10 Note: In the Service Center environment, every user must be defined in the Security File to allow even inquiry access to EXPO and EARS data. This avoids the risk of one State accidentally accessing another State’s data. An individual State, however, allows a default browse access attribute for any user not already defined in the Security File user list. When someone who is not listed as a valid user attempts to enter the system, the data file ID’s will appear as “ES2LKUP”, etc., whereas the “S2” portion of the name is supposed to be the State postal abbreviation (e.g., “AZ”, “CO”, etc.). This produces a CICS ABEND error, which serves as notification that the person needs to be added to the Security File (or that someone has tried to gain unauthorized access to EXPO/EARS).
Related Links
