Options for dividing network security responsibility

When your system participates in a network, you must decide whether to trust the other systems to validate the identity of a user who is trying to enter your system.

Will you trust SYSTEMA to ensure that USERA is really USERA (or QSECOFR is really QSECOFR)? Or will you require a user to provide a user ID and password again?

The secure location (SECURELOC) parameter on the APPC device description on the target system specifies whether the source system is a secure (trusted) location.

When both systems are running a release that supports *VFYENCPWD, SECURELOC(*VFYENCPWD) provides additional protection when applications use SECURITY(SAME). Although the requester does not enter a password on the request, the source system retrieves the user’s password and sends it with the request. For the request to be successful, the user must have the same user ID and password on both systems.

When the target system specifies SECURELOC(*VFYENCPWD) and the source system does not support this value, the target system handles the request as SECURITY(NONE).

Table 1. How the APPC security value and the SECURELOC value work together
Source system	Target system
Architected security value	SECURELOC value	User profile for job
None	Any	Default user¹
Same	*NO	Default user¹
	*YES	Same user profile name as requester from source system
	*VFYENCPWD	Same user profile name as requester from source system. The user must have the same password on both systems.
Program	Any	The user profiles that are specified on the request from the source system
Note: The default user is determined by the communications entry in the subsystem description.