Controlling access to Tivoli Workload Scheduler for z/OS subresources

You can restrict access to IBM Tivoli Workload Scheduler for z/OS data by specifying subresources. This level of protection is useful if you want to permit different users access to a particular IBM Tivoli Workload Scheduler for z/OS function, while allowing the users’ access only to their own IBM Tivoli Workload Scheduler for z/OS data. For example, a user might not need access to all applications, only to payroll applications.

If you do not specify subresources, access to IBM Tivoli Workload Scheduler for z/OS data is determined by a user’s access to fixed resources or, if fixed resources are not defined, by the user’s access to the IBM Tivoli Workload Scheduler for z/OS subsystem. To implement specific protection of IBM Tivoli Workload Scheduler for z/OS data, you must:

• Give users access to the fixed resource that owns the subresource.
• Add the subresource to the list of SUBRESOURCES on the AUTHDEF statement.
• Define to RACF® the RACF resource name that corresponds to the IBM Tivoli Workload Scheduler for z/OS subresource name.
• Set up the required RACF profile for the resource.

Table 26 shows the subresources that you can protect.

If you change a profile for a subresource while IBM Tivoli Workload Scheduler for z/OS is active, the change does not take effect immediately. Three ways to effect the change are:

• Stop and restart IBM Tivoli Workload Scheduler for z/OS.
• Use the modify command (F xxxx,P=GEN followed by F xxxx,S=GEN) to stop and restart the general service subtask.
• Select Service Functions (item 9 on the IBM Tivoli Workload Scheduler for z/OS dialog main menu), and then select RACF Resources.

RACF does not check for a RACF class until that class is activated. You can activate a class by using the CLASSACT parameter of the SETROPTS command. To enable generic profile checking, define the class in the GENERIC parameter of SETROPTS.

Tivoli Workload Scheduler for z/OS subresources and RACF resources

The AUTHDEF statement uses the IBM Tivoli Workload Scheduler for z/OS subresource name to activate RACF checking for an IBM Tivoli Workload Scheduler for z/OS subresource. For example, if you want IBM Tivoli Workload Scheduler for z/OS to verify authorization for application descriptions by checking the application name, you specify the value AD.ADNAME on the SUBRESOURCES keyword of the AUTHDEF statement. The resource name that RACF then checks consists of a 3-character code identifying the subresource, followed by a name specifying the particular data to be protected. For example, to protect application descriptions whose application name is PAYROLL, you define a RACF resource, ADA.PAYROLL, in the RACF resource class that is specified on the AUTHDEF statement.

Here is an example that shows how you could protect the JCL and job library file (JS). This example assumes that:

• The file is protected against update but can be read by any user.
• The owner ID is used to protect access. Table 26 shows the other names that you can select to protect the JS fixed resource.
• User CASHIER has update access to data with owner PAYROLL but has only read access to other data.
• OPCCLASS is the RACF resource class used to protect IBM Tivoli Workload Scheduler for z/OS resources. This name is specified on the AUTHDEF statement.
• The required resources are not defined.

To implement protection:

1. Define the fixed resource that owns the subresource and give universal read access to it:

    RDEFINE (OPCCLASS) JS UACC(READ)

2. Give user CASHIER update access to the JS fixed resource:

    PERMIT JS ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS)

3. Define a RACF resource, JSO.PAYROLL, to RACF and give universal read access to JSO.PAYROLL:

    RDEFINE (OPCCLASS) JSO.PAYROLL UACC(READ)

   JSO is the 3-character code that RACF uses for JS.OWNER.

4. Give user CASHIER update access to JSO.PAYROLL:

    PERMIT JSO.PAYROLL ID(CASHIER) ACCESS(UPDATE) CLASS(OPCCLASS)

5. Define a subresource JSO.* to RACF and give universal read access to this subresource:

    RDEFINE (OPCCLASS) JSO.* UACC(READ)

   This rule prevents the user CASHIER from updating JCL in occurrences that do not have the PAYROLL owner ID.

6. Start checking for the JS.OWNER subresource by specifying JS.OWNER on the SUBRESOURCES keyword of the AUTHDEF statement.

A user’s default access to IBM Tivoli Workload Scheduler for z/OS subresources is determined by the user’s access to IBM Tivoli Workload Scheduler for z/OS fixed resources.

If you base your subresources on application names or owner IDs and these do not have consistent naming standards, you might need hundreds or even thousands of RACF profiles. This would make your subresources difficult to maintain. It would also slow IBM Tivoli Workload Scheduler for z/OS processing, particularly at startup time when all profiles are read in. You can dramatically reduce the number of profiles you need by using consistent naming standards, or RACF generic profiles, or both.