IBM Mainframe Forum

Surrogate job submission in a CICS environment

Batch jobs submitted by CICS can be allowed to run with a USER parameter other than the CICS region's userid, but without specifying the corresponding PASSWORD. This is called surrogate job submission. These jobs have the access authorities of the USER parameter actually specified on the JOB statement. If the PASSWORD parameter is specified on the JOB statement, surrogate processing does not occur.

You (or the RACF security administrator) can allow this by defining a profile in the SURROGAT class. For example, if the CICS region's userid is CICS1, and the job is to run for userid JOE, define a SURROGAT profile named JOE.SUBMIT:

RDEFINE SURROGAT JOE.SUBMIT UACC(NONE)
NOTIFY(JOE)

Further, you must permit the CICS region's userid to act as the surrogate to the profile just defined:

PERMIT JOE.SUBMIT CLASS(SURROGAT) ID(CICS1) ACCESS(READ)

The SURROGAT class must be activated using RACLIST for this protection to be in effect:

SETROPTS CLASSACT(SURROGAT) RACLIST(SURROGAT)

Attention:

Any CICS user, whether signed on or not, is able to submit jobs that use the SURROGAT userid, if the CICS userid has authority for SURROGAT. If your installation is using transient data queues to submit jobs, you can control who is allowed to write to the transient data queue that goes to the internal reader. However, if your installation is using EXEC CICS SPOOLOPEN to submit jobs, you cannot control who can submit jobs (without writing an API global user exit program to screen the commands). CICS spool commands do no CICS resource or command checking.

You can use an EXEC CICS ASSIGN USERID command to find the userid of the user who triggered the application code. Application programmers can then provide code that edits a USER operand onto the JOB card destined for the internal reader.

For a complete description of surrogate job submission support, see the OS/390 Security Server (RACF) Security Administrator's Guide.

Controlling userid propagation

Jobs submitted from CICS to the JES internal reader without the USER operand being specified on the JOB statement run under the CICS region's userid. These jobs have the access authorities of the CICS region itself, and so could potentially expose other data sets in the MVS system.

You (or the RACF security administrator) can prevent the CICS userid from being propagated to these batch jobs by defining a profile in the PROPCNTL class where the profile name is the CICS region's userid. For example, if the CICS region runs under userid CICS1, define a PROPCNTL profile named CICS1:

RDEFINE PROPCNTL CICS1

The PROPCNTL class must be activated using RACLIST for this protection to be in effect:

SETROPTS CLASSACT(PROPCNTL) RACLIST(PROPCNTL)

If the PROPCNTL class is already active, refresh the in-storage PROPCNTL profiles with the SETROPTS command:

SETROPTS RACLIST(PROPCNTL) REFRESH

You (or the RACF security administrator) must issue the SETROPTS command to refresh these profiles. Issuing the CICS PERFORM SECURITY REBUILD command does not affect the PROPCNTL class.