Controlling access to Tivoli Workload Scheduler for z/OS from APPC
Read the following information if you use any of the IBM Tivoli Workload Scheduler for z/OS user interfaces to access IBM Tivoli Workload Scheduler for z/OS using APPC. The interfaces include:
- The IBM Tivoli Workload Scheduler for z/OS API, either from your own transaction program or through the Tivoli Workload Scheduler for z/OS GUI
- The IBM Tivoli Workload Scheduler for z/OS server, from your own PIF programs or ISPF dialogs, or the GUI for Application Description.
Access to IBM Tivoli Workload Scheduler for z/OS through the API or the server can be controlled in two distinct ways: through security provided by:
- APPC/z/OS and RACF®
- IBM Tivoli Workload Scheduler for z/OS and RACF
APPC/z/OS and RACF
The APPC/z/OS component builds a security environment that is passed to the IBM Tivoli Workload Scheduler for z/OS scheduler for the user ID that allocates the conversation. APPC/z/OS requires that a conversation be either trusted or non-trusted. If a conversation is defined as trusted, then the security environment is assumed to have been verified and the allocation is accepted. If a conversation is non-trusted, then the security environment must be passed as part of the allocation.
Access to IBM Tivoli Workload Scheduler for z/OS through PIF or the ISPF dialogs uses a trusted allocation.
Access to IBM Tivoli Workload Scheduler for z/OS through the API, or Tivoli Workload Scheduler for z/OS GUI uses a non-trusted allocation. As an extra level of security, these accesses use a transaction program that must have a security type of PGM or SAME. For Tivoli Workload Scheduler for z/OS GUI, these definitions are made in the Communications Manager.
You must also ensure that a RACF user profile exists in the RACF database for the user ID that is passed in an allocate request.
You can use APPC/z/OS security functions to control:
- Access to LUs
- Access for LU to LU communication
- Access to TPs
- Security within the network
IBM Tivoli Workload Scheduler for z/OS recognizes these TP names:
- Name
- Supplied by
- EQQTRK
- Trackers that communicate with the controller through APPC
- EQQAPI
- User programs (ATPs) that communicate with IBM Tivoli Workload Scheduler for z/OS through the API
- EQQDIA
- The IBM Tivoli Workload Scheduler for z/OS ISPF dialogs
Refer to APPC Management for detailed information about protecting your APPC/z/OS environment. ICSF/MVS Programmer’s Guide describes how you can protect information that crosses a network.
Tivoli Workload Scheduler for z/OS API and RACF
IBM Tivoli Workload Scheduler for z/OS performs security checking at the controller for all TPs that use the API. To establish a conversation, the outbound TP must supply a User_id and password, and optionally a profile that indicates the RACF user group. The User_id must have access to the IBM Tivoli Workload Scheduler for z/OS subsystem resource, which is defined in the APPL class.
A user needs this access to fixed resources for API requests:
- GET
- CP read. SR read is also required to retrieve special resource information.
- PUT
- CP update. RL update is required to change the status of operations or issue ready list commands such as MH or NOP. EXEC update is required to use the EXEC command.
- DEL
- CP update.
- CREATE
- IBM Tivoli Workload Scheduler for z/OS does not support security checking for CREATE requests because a request could be directed to more than one IBM Tivoli Workload Scheduler for z/OS subsystem where security rules differ. You can prevent unauthorized use of CREATE requests through APPC/z/OS security mechanisms by protecting the LU and the TP name.
If you protect IBM Tivoli Workload Scheduler for z/OS data by specifying subresources, users must have the appropriate access to subresources. Table 26 shows the subresources that you can specify for each fixed resource.