IBM Mainframe Forum

giving surrogate access to my tool might not be possible easily

17.8.1 Allowing Surrogate Job Submission

You can allow the use of surrogate users. A surrogate user is a RACF-defined user who has been authorized to submit jobs on behalf of another user (the execution user) without specifying the execution user's password. Jobs submitted by a surrogate user run with the identity of the execution user. For example, if user JOE submits a job with the following JOB statement, JOE is the surrogate user and TOM is the execution user:

//jobname JOB 'accounting-information',USER=TOM

All access checks are done with TOM's user ID. Any auditing records produced by RACF because of the submitted job's actions include the information that the job is a surrogate job (unless the PASSWORD parameter is specified on the JOB statement).

┌─── Attention ──────────────────────────────────────────────────────────┐
│ │
│ A user should not allow another user to act as surrogate user unless │
│ the surrogate user can be trusted as highly as the execution user is │
│ trusted. This is because the surrogate user can do anything the │
│ execution user can do (unless the surrogate user lacks access to a │
│ security label that protects a resource). For example, the surrogate │
│ user can submit a job to copy, alter, or delete the execution user's │
│ data. │
│ │
└────────────────────────────────────────────────────────────────────────┘

The surrogate user must specify the execution user's user ID on the USER parameter on the JOB statement and must not specify a password. If the PASSWORD parameter is specified with a password, surrogate processing is not performed, and audit records generated by the job's activities do not indicate that the job is a surrogate job. This applies not only to jobs submitted through the TSO SUBMIT command, but any time the surrogate user is a RACF-defined user.


| When the SECLABEL class is active and the SETROPTS MLS option is in
| effect:

| If a security label is specified for the submitted job, the specified
| label must be equal to or greater than the current security label of
| the surrogate user, and both the surrogate and execution users must
| have READ authority to the specified label. After job verification is
| complete, the job submitted by the surrogate user runs as if the
| execution user had submitted the job.

| If a security label is not specified for the submitted job but the
| surrogate user has a current security label, the submitted job runs
| with the surrogate user's current security label.

To allow surrogate users, do the following:

Ensure that the installation exit for the TSO SUBMIT command (IKJEFF10) does not prevent users from submitting jobs with job names that do not match their user IDs. The installation exit supplied by IBM meets this requirement, because it does not check the JCL of submitted jobs. For more information, see z/OS TSO/E Customization.

If your installation implemented the sample ICHRTX00 exit from SYS1.SAMPLIB member RACINSTL to enable surrogate user processing, you should migrate to profiles in the SURROGAT class. After RACF is installed, the code in the ICHRTX00 exit that checks $SUBMIT.userid profiles is not used. You should copy the $SUBMIT.userid profiles to SURROGAT profiles as follows:

RDEFINE SURROGAT execution-userid.SUBMIT
FROM($SUBMIT.execution-userid) FCLASS(FACILITY)

Define resource profiles in the SURROGAT class for each execution user who needs to allow others to be surrogate users:

RDEFINE SURROGAT execution-userid.SUBMIT UACC(NONE) OWNER(execution-userid)

Note: Specifying the OWNER operand allows the execution user to issue the PERMIT command for this profile.

To specify that another user can act as the surrogate for an execution user, give the surrogate user READ access authority:

PERMIT execution-userid.SUBMIT CLASS(SURROGAT) ID(surrogate-userid) ACCESS(READ)

Only users and groups that have READ access authority are allowed to submit jobs on behalf of another user.

To check whether a user can submit jobs for another user, make sure the user (or a group the user is a member of) is in the access list with READ access authority:

RLIST SURROGAT execution-userid.SUBMIT AUTHUSER

When you are ready to control access using the SURROGAT profiles, activate the SURROGAT class:

SETROPTS CLASSACT(SURROGAT)

To disable surrogate support for a particular user, delete the profile for that user. To disable surrogate support for all users, deactivate the SURROGAT class.

NJE notes:
The node in which SURROGAT checking occurs depends on the job statements (see "Where NJE Jobs Are Verified" in topic 17.10). For verification done on the receiving node, the SURROGAT checking is done after any translation due to NODES profiles. (See "Understanding NODES Profiles" in topic 17.15.1.1.)

If the submitter of a job is a started procedure, the execution node is not checked during SURROGAT processing.