Default Option - Figure #1:
CONNX for CICS / VSAM is implemented as a Windows PC client and a set of CICS programs, including a Listener (Transaction NX00 / Program CNXRUN) and a Server (Transaction NXS0 / Program CNXVSAM). When a user connects from a client application through a supported interface (ODBC, JDBC, OLE DB or .NET), the client CONNX user ID / password is mapped to a CICS user ID / password via the CONNX Data Dictionary.
The encrypted CICS user ID / password is sent via TCP/IP to the CONNX CICS TCP/IP Listener Transaction NX00, which decrypts the user ID / password and executes the CICS VERIFY PASSWORD command, which in turn invokes the installed external security manager software (RACF, ACF/2, CA-Top Secret) to verify the user ID / password. Refer to steps 1 through 3 in Figure 1.
If the user ID / password sent from the CONNX PC client is valid, the CONNX CICS / TCP/IP listener transaction NX00 starts CONNX server transaction NXS0 using the CICS command:
START TRANSID (NXS0) USER(user ID)
Where user ID is the CICS user ID sent from the CONNX client. In order for this command to succeed, the user ID which started the NX00 transaction (user ID #0) must have surrogate authority defined for the CICS client user ids (user IDs #1, #2, and #3). This prerequisite is documented in the CONNX User Reference Guide. If the start of transaction NXS0 succeeds, then transaction NXS0 sets up a separate TCP/IP connection to the invoking CONNX PC client.
CONNX PC Client requests and VSAM data responses flow back and forth directly from the CONNX PC client to the dedicated NXS0 transaction. Refer to steps 4 and 5 in Figure 1. For the default case, the host-side (RACF, ACF/2, CA Top Secret) security rules defined for the NXS0 user IDs (#1, #2, or #3) determine the type of VSAM file access granted to the CONNX PC client.
The default security option observes the host-side security rules defined for CICS user ID / password verification, and for each CICS user ID or group of user IDs for VSAM file access. In order for these rules to be enforced, each CICS user ID sent from the CONNX PC client must be attached to a separate NXS0 transaction via the START TRANSID command. This option requires that the user ID that starts transaction NX00 must have surrogate authority to start transaction NXS0 for every CICS user ID sent from the CONNX client.
Figure 1:
Alternate Option - Figure #2:
The host-side security rules for user ID / password verification and dataset access can be enabled or disabled for CONNX client-server connections via a CONNX environment variable (CNXNOPREAUTHORIZE). Setting CNXNOPREAUTHORIZE to a non-zero value instructs the CONNX CICS TCP/IP Listener and Server programs to bypass CICS user ID / password verification. Transaction NX00 starts CONNX server transaction NXS0 using the CICS command:
START TRANSID (NXS0)
If the start succeeds, then client requests and VSAM data flow from the CONNX PC client to the NXS0 transaction and back via a dedicated TCP/IP socket connection. In this case, the host-side security rules defined for the NX00 user ID (#0) attach to each NXS0 transaction started on behalf of a CONNX client, and determine the type of VSAM file access granted to the CONNX PC client.
This security option bypasses the need to define surrogate user ID relationships, but all dataset access derives from the single user ID which starts transaction NX00. An advantage to this approach is that host-side VSAM data set security rules for CONNX PC clients need only be defined for one user ID.
CONNX Client-Side Security Enhances Host-Side Security
For both options, the CONNX Administrator should consider taking advantage of the client-side security features implemented in the CONNX Data Dictionary (CDD). The first line of defense is only to import selected VSAM files into the CDD. Additionally, the CONNX Administrator can restrict access to VSAM files based on CONNX user IDs and groups defined via the security menu features in the CONNX Data Dictionary Manager.
In most cases, a physical VSAM file is composed of multiple logical files or sub-files. The CONNX Data Dictionary Manager can be used to define and enforce security rules based on these logical files, as well as on the underlying physical data sets. Further, column- and row-level security can be implemented by defining one or more CONNX views against the imported VSAM physical or logical files, and by authorizing individual or groups of CONNX user IDs to execute the CONNX client-side views.
The CONNX client-side approach to security complements and enhances most host-side security products, such as RACF, ACF/2, or CA-Top Secret, which implement access rules on a per-physical VSAM file basis. In all cases, the security rules defined in the CONNX Data Dictionary take precedence over the host-side security rules. For more information on CONNX client-side security, refer to the other topics described in the CONNX Security section.
Figure 2:
