Can you secure a CICS screen that is called by the application program? Phil Emrich, our CICS expert, explores this question in this tip.
Most CICS transactions are designed such that they process a particular set of input data, where the format of the screen or panel was generated by a BMS map. A response is created which may also use a BMS map, either the same one from which they processed the input data or a different map, and then the transaction would terminate.
A new transaction would then be initiated to process any subsequent input and the process would be repeated. Most transactions are designed to create only one set of output, typically using a single BMS map or a set of maps to construct the screen or panel displayed. There are a number of techniques for a CICS transaction to generate an output screen or panel. Using a BMS map is only one of the techniques, though probably the most common. In this environment the security check for the transaction code is typically sufficient to "protect" any information that the transaction might process on input or display on output.
CICS will call the external security manager, either RACF or an equivalent product, for every CICS transaction that is initiated. RACF will determine whether the user initiating the transaction is authorized to do so referring to the profiles you have defined in the TCICSTRN and GCICSTRN general resource classes. This authorization check is based on the 4-character transaction code used to initiate the transaction.
CICS also provides the option to perform additional security checks during the execution of CICS transaction when it requests access to some CICS resources via EXEC CICS API commands. The types of resources for which CICS will perform this additional authorization, if the RESSEC option is specified in the CICS TRANSACTION definition, include the names of programs, VSAM files, temporary storage queues and transient data destinations, but does not include BMS MAPSET names.
If you have one or more cases where a single transaction has been designed such that it may display one of several possible output screens or panels of information then you may be able to use the resource security (RESSEC) capability if each of the possible screens that may be produced happens to be produced by a separate application program. In this case you could utilize RACF profiles defined in the MCICSPPT and NCICSPPT general resource classes and allow any particular screen to be produced only for those groups of users who were authorized for the program that produces that screen.
If this option doesn't fit the design of some or all of the transactions that are capable of producing more than one different output screens or panels there is another technique that could be employed to control which particular screens a given user could cause to be displayed.
This technique, unlike the previous one, would require some change to the application program producing the screen or screens. This approach would involve issuing the EXEC CICS QUERY SECURITY command within the program to determine whether the user had the authority to have the transaction generate a particular output screen. The particular screen might be explicitly requested via some information entered by the user or the program may simply generate one of several versions of the output based simply on the authority of the user. In either case the program would need to issue an EXEC CICS QUERY SECURITY command specifying some resource name that corresponds to the authority of users to have the transaction generate specific output screens or panels.
If a particular output screen is requested explicitly, then you might choose to use a series of resource names that correspond to each screen that may be requested.
The EXEC CICS QUERY SECURITY command will allow the program to determine whether any given user has authority to request the corresponding screen. The EXEC CICS QUERY SECURITY command will cause CICS to call the external security manager in the same manner as CICS does for transaction or resource security and will return to the program the level of access the user has to the resource specified.
In addition to the resource name on the EXEC CICS QUERY SECURITY command you must also specify a CICS resource type or a RACF resource class. If you can adopt a resource naming convention that is consistent with the resource name length limitations of one or more of the CICS resource types then you can use one of the CICS resource types rather than an explicit RACF resource class.
If for example you can limit you resource names to eight characters you could choose to use either the PROGRAM, FILE or PSB types. If you were to use either the PROGRAM or FILE types and you used CICS resource security for either of these resource types in any of you transactions you would want to ensure that the resource names you chose did not conflict with an program or file names in use. If you were to use BMS MAPSET names, for example, you could choose to specify RESTYPE(PROGRAM) as CICS requires that any BMS MAPSET name be different from that of any program. You would then define RACF profiles in the MCICSPPT and/or NCICSPPT general resource classes to correspond to the screens you wished to control
There are any number of variations on the manner in which the EXEC CICS QUERY SECURITY command can be used to address a variety of security related requirements within CIC transactions depending on how the transaction happens to have been designed and the specific type of control you wish to impose. Hopefully, the explanation I've provided will be sufficient to at least clarify the basic options you have for imposing security controls on the screens or panels produced by CICS transactions.
