Security checking of transactions running under CEDF

When a transaction runs under the CEDF transaction, CICS® uses the CMDSEC attribute in the definition of the target transaction and the CEDF transaction:
Table 1. Security checking for transactions running under CEDF
CEDF target transaction Security checking
CMDSEC(YES) CMDSEC(YES) Any access to CICS commands causes a security check.
CMDSEC(YES) CMDSEC(NO) Any access to CICS commands causes a security check.
CMDSEC(NO) CMDSEC(YES) Any access to CICS commands causes a security check.
CMDSEC(NO) CMDSEC(NO) Access to CICS commands does not cause a security check.

To achieve the expected security processing for a transaction when it runs under CEDF, ensure that CMDSEC for the CEDF transaction definition is set to NO. The IBM®-supplied definition of CEDF in the DFHEDF group specifies CMDSEC(YES). Definitions in the IBM-supplied groups cannot be modified, so to change the definitions, copy them to another group.

When CEBR or CECI is invoked from within EDF it is transaction-attach checked. In the same environment the CMDSEC and RESSEC definitions are forced regardless of what is coded in their transaction definitions.

When CEDF is used to test a transaction, the authorities of the user executing the CEDF transaction are taken into account, as well as those of the user executing the transaction being tested. For each resource accessed by the tested transaction, both users must have access authority, otherwise authority, otherwise a NOTAUTH condition is raised. This applies to all resource checks:
Note: When an EXEC CICS SIGNON, EXEC CICS VERIFY PASSWORD, or EXEC CICS CHANGE PASSWORD command is issued by a transaction running under CEDF, the password (and new password, where applicable) is blanked out.