A decentralized security strategy

Most Tivoli Workload Scheduler for z/OS work is delegated to representatives of the end-user departments. They perform all Tivoli Workload Scheduler for z/OS functions (including reruns and JCL corrections during the day) but only for the applications in their own department. During the second and third shifts, machine-room operators take care of reruns and JCL corrections for all departments.

These RACF® groups are defined:

Group: Contains
OPCGROUP: Most of the Tivoli Workload Scheduler for z/OS users. Unlike the users in a centralized installation, these users work alone and perform all Tivoli Workload Scheduler for z/OS functions on a limited number of applications.
OPCSPEC: The schedulers and system support people who keep Tivoli Workload Scheduler for z/OS running continuously.
OPER: The people who correct jobs that end in error overnight.

The major difference from a centralized installation is that authority is divided by department, not by Tivoli Workload Scheduler for z/OS function. The decentralized location relies mainly on Tivoli Workload Scheduler for z/OS subresources for security. This makes name standards more important if the number of profiles is to be kept to a minimum. The administrator must decide which subresource names to use. For example, access to applications could be restricted by job name, owner ID, or authority group ID. Critical functions such as REFR (refresh) should not be decentralized.

External access to IBM Tivoli Workload Scheduler for z/OS

As in the centralized installation, update access to Tivoli Workload Scheduler for z/OS data sets is given to members in the OPCSPEC group. In a decentralized installation, though, all other groups must have ACCESS(NONE). This prevents members of OPCGROUP or OPER from reading data that belongs to other users. With read access to the Tivoli Workload Scheduler for z/OS data sets, a user could run a utility program outside the Tivoli Workload Scheduler for z/OS subsystem to look at data that belongs to another user.

Access through the IBM Tivoli Workload Scheduler for z/OS subsystem

These authorization layers are defined:

Subsystem access: All groups are given update access to the Tivoli Workload Scheduler for z/OS subsystem in the APPL class. This lets all users update most Tivoli Workload Scheduler for z/OS functions (fixed resources) for their own department. The APPL class specification is the default if a fixed resource is defined.
Another way to handle fixed resources is to define them individually and give update access to OPCGROUP and OPCSPEC. But the OPER group needs update access only to CP, JS, and RL (for JCL corrections and reruns). They could have ACCESS(NONE) to the rest of the fixed resources. This would prevent them from entering any Tivoli Workload Scheduler for z/OS dialog that they do not need for their work.
Critical functions: Some fixed resources, such as JSUB and REFR, represent functions that have a serious impact on Tivoli Workload Scheduler for z/OS operation, and can be turned on or off with a single keystroke. Access to these functions should not be decentralized. Access is restricted to OPCSPEC to reduce the risk of accidental errors:
```
 RDEFINE (OPCCLASS) ARC UACC(NONE)
 PERMIT ARC ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS)
```
These steps are repeated for ETAC, JSUB, and REFR.
Subresource protection: The installation protects access to applications and JCL using subresources. But the installation does not have consistent naming conventions for applications. So subresource protection is implemented through the owner ID and job name, which have consistent naming conventions.
1. These subresources are specified on the AUTHDEF statement:
  
  AD.JOBNAME LT.OWNER
  
  AD.OWNER JS.JOBNAME
  
  CP.JOBNAME JS.OWNER
  
  CP.OWNER RL.OWNER.
  
  The subresources AD.JOBNAME, CP.JOBNAME, and JS.JOBNAME are used to prevent users from specifying unauthorized job names when they create an application. Otherwise, Tivoli Workload Scheduler for z/OS could be used to submit a job with a job name that the users do not normally have access to.
2. The RACF resource names are defined with ACCESS(NONE), so the default access for all users to these subresources is NONE:
```
 RDEFINE (OPCCLASS) ADJ.* UACC(NONE)
```
  This is repeated for ADO.*, CPJ.*, CPO.*, LTO.*, JSJ.*, JSO.*, and RLO.* resource names.
3. When profiles are created, OPCGROUP members receive the authority to decide the access list to their own subresources.
  OPCSPEC is given update access in case this is needed for support:
```
 PERMIT ADO.* ID(OPCSPEC) ACCESS(UPDATE) CLASS(OPCCLASS)
```
  This is repeated for each subresource.
4. OPER is given access to the CP.OWNER, CP.JOBNAME, JS.JOBNAME, JS.OWNER, and RL.OWNER subresources so that operators can work during night shifts:
```
 PERMIT CPO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT CPJ.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT JSJ.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT JSO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
 PERMIT RLO.* ID(OPER) ACCESS(UPDATE) CLASS(OPCCLASS)
```

If many resources with similar names have the same access list, the resources can be grouped under generic profiles with the percent sign (%). For example, the ADO, CPO, JSO, LTO, and RLO profiles could be specified as one profile, %%O.*. Note that *O.* is an invalid RACF entity.

Many RACF resource names must be defined in the OPCCLASS resource class to protect the data of every owner. Each subresource has its own profile, unless some subresources can be grouped under generic profiles. For example, the owner IDs PAYROLL, PAYROLL-A, and PAYROLL-02, can be grouped as PAYROLL*.

Defining profiles might seem like a lot of work, but the number of owners is usually limited, and you can often use generic profiles. Because you can have many more job names than owner IDs, generic definitions of job names are even more important. Most jobs can be handled with a small number of generic profiles.

	AD.JOBNAME	LT.OWNER
	AD.OWNER	JS.JOBNAME
	CP.JOBNAME	JS.OWNER
	CP.OWNER	RL.OWNER.