Authorizing jobs

You can control which network jobs are authorized for processing at your installation on the basis of submitter's user ID, group name, or security label associated with the inbound job.

To authorize or restrict jobs entering your system from another node, define a NODES profile that specifies the criteria on which jobs are accepted. Ask your JES system programmer for the following:

The node names from which you expect jobs
The user IDs or group names from which you expect jobs
The security labels that you should accept
The universal access authority, which determines how JES3 processes the job. Table 1 lists the universal access authorities you can assign and defines the validation that RACF® performs.

Table 1. NODES class operands and the UACC meaning for inbound jobs
Type of check (operand)	UACC
Type of check (operand)	NONE	READ	UPDATE	CONTROL or greater
User ID (USERJ)	Fails the job.	Verifies all security information available including password validation.	If the job is from an uplevel node, that is, if a non-default valid security token is passed, propagates the submitter's or translated security information as the owning security information without password validation. See Understanding mixed security environments. If the job is from a default or downlevel node, processing is the same as for a UACC of READ.	Same as UPDATE, but default security or downlevel information is allowed. CONTROL allows a downlevel system to send jobs to your node without passwords. RACF does not validate passwords. See Understanding mixed security environments.
Group name (GROUPJ)	Fails the job.	Translates group name to that specified in ADDMEM. If ADDMEM is not specified, uses the group name received.
Security label (SECLJ)	Fails the job.	Translates the submitter's SECLABEL to that specified in ADDMEM. If ADDMEM is not specified, uses the security label received.
Note: For more details on how NJE jobs are processed, see Authorizing jobs.

Note: If no profile exists for a job when the NODES class is active or if the NODES class is inactive, RACF performs only user ID, group name, and password validation without performing any translation.

If no profile exists for a job when the NODES class is active, RACF verifies all security information available and a valid password and user ID must be specified on the job card.

You can further reduce the risk of security exposures by allowing jobs to be submitted from other nodes without requiring a password if the sending node properly validates and transmits a user's identity. You can either allow the submitter's identity (that is, the user ID and security label) to be propagated to the job or you can specify that the submitter is a surrogate submitter who can submit jobs on behalf of other users without needing a password.

For either case, you indicate in NODES class profiles which nodes are trusted to provide valid submitter identity information. You can restrict the trusted information to specified user IDs, group names, or security labels, if desired.

This submitter identity information in combination with user data on the job card is used to determine the user identity to be used for the job.

If no user ID or password is specified on the job card, the submitter's identity is propagated to the job.¹
If a user ID but no password is specified, the user ID is allowed if the submitter is authorized as a surrogate for that user ID.¹
If both user ID and password are specified on the job card, the submitter's identity is not propagated to the job, but will still be used for JESJOBS checking. Normal password validation is performed.