Surrogate user
A RACF arrangement that lets one user act as another, most often to submit jobs that run under a different user ID.
Also written SURROGAT class, submit as another user, USER= on JOB, userid.SUBMIT
Normally a job runs under the user ID of whoever submitted it. A surrogate user is someone allowed to submit work that runs under another user ID, without knowing that ID's password.
This is set up in the RACF SURROGAT class. A profile named after the target user, such as PRODBAT.SUBMIT, controls who may submit jobs as PRODBAT. Anyone with READ access to it can code USER=PRODBAT on a JOB statement, and the job runs with PRODBAT's authority.
The most common use is the batch scheduler. Production jobs run under production user IDs, and the scheduler's own ID is a surrogate for them, so it can submit everything. People in production support may also be surrogates for some IDs, so they can rerun jobs. The same class controls other kinds of acting on behalf of another user, such as in Unix System Services.
Being a surrogate for an ID means having that ID's access, so security teams treat these permissions as carefully as the access itself, and auditors check them.
Where can I learn this hands-on?
Right here, at ZedBank. You take a junior job at a simulated bank and learn each part of the work by doing it, with Zed beside you. There's nothing to install.
Start at ZedBankRelated
- RACFThe security manager for z/OS, which decides who may sign on, read a dataset, or run a transaction.
- General resource profileA RACF profile that protects something other than a dataset, such as a CICS transaction, a program or an operator command.
- Batch schedulerSoftware that submits production jobs automatically in the right order, at the right time, based on what has already succeeded.
- JOB statementThe first statement in every job, giving it a name and telling the system who is running it and how to treat it.
- RACF user IDA person or program's identity on the system. Short, unique, and the basis of every access decision.