Controlling access to resources

Before Tivoli Workload Scheduler for z/OS performs any request initiated by a user, a security verification check is passed to the system authorization facility (SAF) to ensure that the user is authorized to access all resources needed to run the request. A user can request Tivoli Workload Scheduler for z/OS services from:

Any security software that interfaces with SAF also works with Tivoli Workload Scheduler for z/OS. For this section, the security product is assumed to be RACF®.

The z/OS router service calls RACF to perform authority checks. It provides an installation exit that you can use instead of, or in addition to, RACF to perform resource control functions.

Use the Tivoli Workload Scheduler for z/OS reserved resource class IBMOPC.

The default class for Tivoli Workload Scheduler for z/OS is OPCCLASS. If you use a different class name, you must specify it in the AUTHDEF statement. Generally, this means specifying CLASS(IBMOPC) in the AUTHDEF statement. If you are running more than one Tivoli Workload Scheduler for z/OS system, for example a test system and production system, you might want to define more than one RACF class. By using different CLASS parameters in each AUTHDEF statement, you can specify a different authorization scheme for each system.

To control access to Tivoli Workload Scheduler for z/OS functions, give at least one TSO user-class authority to the resource class. This TSO user can then allow other Tivoli Workload Scheduler for z/OS users to access resources as needed.

Tivoli Workload Scheduler for z/OS also uses the APPL resource class. Define the subsystem name as a resource in the APPL class.The easiest way to do this is to have the RACF administrator give class authority to the APPL resource class to one TSO user. This TSO user defines the subsystem name (for example, OPCC) to the APPL resource class by entering: 

/*Define subsystem resource*/
RDEFINE APPL OPCC  UACC(NONE)

See RACF Command Reference and RACF Administrator’s Guide if you are unfamiliar with this process.

When the subsystem name is defined to RACF, you can give other TSO users access to Tivoli Workload Scheduler for z/OS. For example, to allow the TSO user OPCUGRP to access OPCC with an update access authority by default, enter:

/*Permit access to Tivoli Workload Scheduler for z/OS*/
PERMIT OPCC ID(OPCUGRP) ACCESS(UPDATE) CLASS(APPL)

For remote dialog users and remotely run PIF applications, the server will do the authority checking; it will check both the APPL class subsystem name resource and the scheduler fixed resources. The user for which the server does authority checking is:

Permitting access to the controller through the API

If you use the API, you can control access to the controller through the security functions of both APPC/MVS and Tivoli Workload Scheduler for z/OS. Ensure that you consider both these environments when you update RACF. For more information about controlling access to Tivoli Workload Scheduler for z/OS through the API, see Tivoli® Workload Scheduler for z/OS®: Customization and Tuning.