APPC transaction security

The security options for APPC/IMS and LU 6.2 application programs are quite extensive. The partner systems can range from a single-user terminal or workstation to a multi-user system. All systems can have their own complex security environment. Security for IMS can be simple or complex.

Every transaction program name (TPN) must pass a security check before it is executed. The user ID that initiates the transaction is identified on the LU 6.2 format header (FMH5). If no user ID exists because you specify SECURITY=NONE, you can only access resources that are not defined with UACC (NONE). Any TPNs that are accessible in all circumstances should not be defined with UACC (NONE). The TPN security definition is required.

z/OS® security consists of two parts. First, z/OS authenticates the transaction user. The LU 6.2 transaction contains security information. The FMH5 contains the user ID, a profile name, which is used as the group name, and security options. You supply both the user ID and password. The user ID is defined to RACF®, and the password must be valid for the user ID.

If Already_Verified is specified in the FMH5, the sending system verifies the user ID. This user ID must be defined to RACF on the receiving z/OS system. No password is needed in this case.

If SECURITY=NONE is specified, z/OS does no checking. Instead, z/OS builds a special security profile that corresponds to SECURITY=NONE. This allows access to z/OS and APPC/IMS resources that have UACC specified at any level other than NONE. Resources with UACC (NONE) or without a UACC specified cannot be accessed.

After the user ID is established, z/OS verifies that the user ID can execute the specific transaction. z/OS verifies that the user ID's access profile has ACCESS (EXECUTE) for the entity dbtoken.x.tpname in the CLASS (APPCTP). The value of dbtoken is the dbtoken value specified in the TP_Profile data set. Based on the APPCTPxx parameter specified for this LU, the value of x is either the user ID, group or SYS1.

If either of these security checks fails, z/OS rejects the transaction, and IMS is not informed of it. z/OS can also check:
  • Session-level security (RACF resource class APPCLU)
  • Port of entry (RACF resource class APPCPORT)
  • Local application (RACF resource class APPL)
The IMS administrator should verify that these security checks are successful.

Related reading: For more information on coding the RACF resource classes, see z/OS MVS™ Planning: APPC/MVS Management.

The security check in IMS is based on the IMS transaction code or executed command name. If the TPN is DFSAPPC, no additional security check occurs. If RACF is used on your system, z/OS rejects the transaction if RACF is not active. The IMS command name or transaction code associated with the TPN is used in the RACF resource class associated with this IMS ('C' or 'T'). RACF checks IMS commands and transactions for all other IMS terminal types in the same way.

If the RACF check is successful, the Transaction Authorization exit routine (DFSCTRN0) is called for transactions, and DFSCCMD0 is called for command authorization. However, the following rules apply to RACF:
  • For commands, default security only applies if RACF is not used.
  • For remote transactions, RACF is optional.
Otherwise, the exit routines make the security decision.

The intended environment executes APPC/IMS with RACF security active. It is possible to run with RACF not active in the APPC/IMS system, but it is not possible to run with RACF not active in the z/OS system. In this sense, RACF is mandatory for LU 6.2.

The complexity of the security environment is derived partly from the many resources involved (VTAM®, z/OS, and IMS) and the granularity of protection that is possible. The security definitions must be closely coordinated for successful operation of the application system.