Summary

APPC/MVS and RACF® provide a number of security mechanisms to protect APPC/MVS TPs and the z/OS system in a cooperative processing environment. The mechanisms that you use depend on the APPC applications you install and the extent to which you want to protect them.

APPC applications may provide for security by passing security information, including user IDs and passwords, on allocate requests from the outbound to the inbound TP. Table 1 shows what LU or conversation security mechanisms you can implement, based on the security information passed.

Table 1. Security Mechanisms Available, based on Application Security Types
Application Security	LU Security Mechanisms	Conversation Security Mechanisms
NONE	Supported	Not supported
SAME	Supported	Supported
PGM	Supported	Supported

You can use the LU security mechanisms for any application, including those that pass no security information. The LU security mechanisms protect APPC/MVS logical units, by verifying the authority of other LUs to establish communication sessions with them, and the level of security needed on any conversation that crosses the session. You can also ensure that specific LU names are defined to VTAM® by APPC only.

You can use the conversation security mechanisms for applications that pass a user ID on the allocate request. The conversation security mechanisms provide a security environment for TPs running on MVS, and they let you control access, by user ID, to LUs, from LUs, and to TPs and related information.

Finally, for higher security in a cooperative processing environment, you can use a cryptographic product such as IBM's Integrated Cryptographic Service Facility/MVS to encrypt and decrypt data and security information that crosses the network between TPs in an APPC application.

Table 2 summarizes RACF classes and resource names, and how they affect APPC.

Table 2. Summary of RACF Classes and Resource Names
RACF class and profile naming convention	Function
In class APPCLU, profiles with the following names: `lnetwork-id.local-lu-name.pnetwork-id.partner-lu-name lnetwork-id.local-lu-name.partner-lu-name lnetwork-id.generic-name.pnetwork-id.partner-lu-name lnetwork-id.generic-name.partner-lu-name`	Define LU-LU security. See Defining LU-to-LU Access Authority with RACF APPCLU Profiles
In class APPCPORT, profiles with the following names: `luname`	Control which LU the user's request can come from. See Controlling User Access from LUs
In class APPCSERV, profiles with the following names: `dbtoken.tpname`	Control server access to clients. See z/OS MVS Programming: Writing Servers for APPC/MVS.
In class APPCSI, profiles with the following names: `dbtoken.SYS1.symdname`	Control the user's access to side information. See Controlling User Access to Side Information
In class APPCTP, profiles with the following names: `dbtoken.level.tpname`	Control the user's access to TP profiles. See Controlling User Access to TPs
In class APPL, profiles with the following names: `luname` or `genericname`	Control use of local LUs. See Controlling User Access to LUs
In class FACILITY, a profile with the following name: `APPCMVS.DBTOKEN`	Controls the user's access to database tokens. See Controlling Access to Database Tokens
In class FACILITY, profiles with the following names: `APPCMVS.TP.MULTI.generic-userid`	Control the user's access to multi-trans TP profiles. See Protecting Multi-Trans TP Profiles
In class FACILITY, profiles with the following names: `ATBTRACE.netid.lu_name.tp_name`	Controls the user's ability to collect API trace data. See Controlling Ability to Collect API Trace Data
In class PROGRAM, profiles with the following names: `ATBINMIG` or `ATBSDEPE` or `ATBSDFMU`	Protect TP profile data sets and side information data sets. See Giving Program Access to the APPC/MVS Administration Utility
In class VTAMAPPL, profiles with the following names: `acbname`	Protect ACBs. See Controlling the Use of VTAM ACBs.