Determining the Application's Security Type

The first step in protecting an application is to determine what security information, if any, the inbound TP requires. APPC applications that you write or install will provide one of three types of security, as specified on the Allocate call:

NONE

The outbound TP passes no security information. The conversation cannot use conversation security mechanisms.

SAME

The outbound TP indicates that the inbound TP should have the same security as the outbound TP. APPC provides the following security information, if any is available, from the outbound TP to the inbound:

A user ID
A security profile name, which APPC/MVS treats as a group ID
An already verified (AV) indicator.
This security information is obtained from a number of different sources, depending on the current execution environment and the input parameters specified. If the user is authorized, uses an MVS-specific Allocate service (for example, ATBALC5), and specifies a valid User_Token parameter, APPC will use this to obtain a user ID and, if available, a profile name. If this is not specified, APPC will send the user ID associated with the current application work context, if this is available. Otherwise, APPC will send the user ID and, if available, a profile name that is associated with the current executing task, or if unavailable, from the current address space.

If no security information is available for the outbound TP, or the inbound system does not support already verified, no security information is passed and the security type is treated as NONE.

(If an allocate request is made from MVS using CMALLC, the CPI Communications Allocate call, the security type is always SAME.)

PGM

The outbound TP specifies a user ID, password and optional security profile name, which RACF® treats as a group ID. The outbound TP passes these to the inbound system for verification.

An alternative to specifying both a user ID and a password is to specify a user ID only, provided that the TP specifying the user ID has the necessary surrogate authority to the specified user ID. Requests that use this technique will send the already verified (AV) indicator to the inbound TP.

For a general description of surrogate user authorization, see z/OS Security Server RACF Security Administrator's Guide. The specific steps needed to set up surrogate authorization for APPC/MVS are as follows:

Identify the user ID associated with the address space in which the TP is issuing the Allocate request. For batch jobs and TSO/E sessions, a user ID is already associated with the address space. For started tasks, the security administrator needs to associate a user ID with the address space of the started task, using the STARTED class in RACF, the RACF started procedure table (SPT), or both (recommended).
For each user ID that needs to use PGM security without a password, define a resource profile in the SURROGAT class as follows:
```
RDEFINE SURROGAT ATBALLC.userid UACC(NONE)
```
If generic profile checking for the SURROGAT class has been activated by the RACF security administrator, you can also create generic profiles to allow APPC/MVS surrogate authorization for multiple users. If SURROGAT profiles named ATBALLC.* and ATBALLC.FRED both existed, ATBALLC.FRED would control APPC/MVS surrogate authorization for FRED, and ATBALLC.* would control APPC/MVS surrogate authorization for all other users. For more information on activating generic profile checking in RACF, see z/OS Security Server RACF Security Administrator's Guide.
Give the APPC TP that needs surrogate authorization READ access to the ATBALLC.userid profile created in the previous step:
```
PERMIT ATBALLC.userid CLASS(SURROGAT) ID(userid-of-the-APPC-TP) ACCESS(READ)
```
where
userid

is the user ID that the TP specifies on the Allocate call without a password.

userid-of-the-APPC-TP

is the user ID associated with the address space in which the TP is issuing the Allocate request.
For this APPC/MVS support to function, you must activate the SURROGAT class. In addition, APPC/MVS requires that the SURROGAT class be RACLISTed:
```
SETROPTS CLASSACT(SURROGAT) RACLIST(SURROGAT)
```

At this point, the user ID associated with the TP has authorization to specify a user ID other than its own without specifying a password.

When the inbound TP resides on MVS, each field of security information (user ID, password, and optional security profile) on an allocate request must not exceed 8 non-blank characters in length. If any of the characters are lowercase, APPC/MVS changes them to uppercase before user verification.

Figure 1 shows an example of providing security information on an allocate request. In the figure, TPA specifies a security type of PGM and passes a user ID and password. TPB's system uses RACF security mechanisms to verify that information, verify access to TPB, and set up TPB's security environment. If TPA specified a security type of SAME, APPC itself would extract and pass any available security information on the allocate request.

Figure 1. Passing Security_PGM Information on an Allocate Request

If you have an APPC application with a inbound TP on MVS, once you know what security information the outbound TP is passing on its allocate request, you can decide how you want to verify and use that information. In other words, you can decide what RACF security mechanisms to use to protect the inbound TP and its LU.

The security mechanisms are divided into two categories:

LU security to protect APPC/MVS logical units
Conversation security to protect APPC/MVS transaction programs.