Controlling access to Tivoli Workload Scheduler for z/OS using Dynamic Workload Console

Read the following information if you are using Dynamic Workload Console to access Tivoli Workload Scheduler for z/OS using TCP/IP.

The z/OS® connector performs a security check when a user tries to use Dynamic Workload Console of IBM Tivoli Workload Scheduler for z/OS, by checking the user ID and password. The z/OS connector associates each user ID and password with an administrator.

Tivoli Workload Scheduler for z/OS resources are currently protected by RACF®.

The Dynamic Workload Console user should have to enter only a single user ID and a password combination, and not provide two levels of security checking (at z/OS connector level and again at Tivoli Workload Scheduler for z/OS level).

The security model is based on z/OS connector security handling initial user verification, and, at the same time, obtains a valid corresponding RACF user ID. This makes it possible for the user to work with the security environment in z/OS.

z/OS security is based on a table that maps the administrator to a RACF user ID. When a z/OS connector connects to Tivoli Workload Scheduler for z/OS, the z/OS connector administrator is mapped to the corresponding user ID. Therefore, ensure that the administrator ID is associated with a RACF user ID in the USERMAP parameter of the SERVOPTS initialization statement. The RACF user ID does not need to have particular permissions to the Tivoli Workload Scheduler for z/OS resources. For details about how to map a user ID to a RACF user ID, see Using a new server initialization parameter to associate a RACF user ID.

For any operations performed through Dynamic Workload Console, ensure that the Dynamic Workload Console user ID is associated with a corresponding RACF user ID. The RACF user ID must have the permissions required to access the Tivoli Workload Scheduler for z/OS resources.

Tivoli Workload Scheduler for z/OS server uses the RACF user ID to build the RACF environment to enable the user to access Tivoli Workload Scheduler for z/OS services.

You can obtain the RACF user ID in either of the following ways:

Using the RACF Tivoli-supplied and predefined resource class TMEADMIN. For details, see Creating the TMEADMIN class to associate a RACF user ID.
Using a new server initialization parameter (SERVOPTS USERMAP) to define a member in the file identified by the EQQPARM DD statement in the server startup job. If the USERMAP parameter is specified for the SERVOPTS statement, the TMEADMIN RACF class is ignored. For details, see Using a new server initialization parameter to associate a RACF user ID.

This example shows the authentication process performed by the z/OS connector when you connect as a Dynamic Workload Console user. Suppose that:

The name of the host on which the z/OS connector runs is ROME1.
The z/OS connector user is named ZCONN1.
The Dynamic Workload Console user ID with which you connect to the z/OS connector is GRAPHUSR.

When GRAPHUSR connects to the z/OS connector, this user ID is authenticated on ROME1. Also, ZCONN1 is authenticated on the z/OS engine by providing the following credentials:

USER ZCONN1-AT-ROME1-domain RACFUSER (TSOuser)

where TSOuser is the TSO user ID with which the Tivoli Workload Scheduler for z/OS dialogs are run.

When GRAPHUSR performs an operation, the z/OS connector uses these credentials, therefore it is required that both GRAPHUSR and ZCONN1 are associated with a RACF user ID. The RACF user ID associated with the z/OS connector user does not need to have particular permissions to the Tivoli Workload Scheduler for z/OS resources, while the RACF user ID associated with the console user needs the permissions to perform the required operations.

Creating the TMEADMIN class to associate a RACF user ID

Make sure your operating system has the Security Server feature.

Create the TMEADMIN class for mapping the administrator ID and host name to the RACF user ID.

Note:

If RACF is your security product and your operating system does not have the Security Server feature, you can use the supplied samples to create the following:

RACF TMEADMIN class EQQ9RFDE. Use the following macro, which you can access in the EQQ9RFDE member of SEQQSAMP library:

TMEADMIN ICHERCDE CLASS=TMEADMIN,
                             ID=129,
                             MAXLNTH=246,
                             FIRST=ALPHANUM,
                             OTHER=ANY,
                             POSIT= 26,
                             OPER=NO,
                             DFTUACC=NONE,
                             DFTRETC=8,
                             RACLIST=ALLOWED,
                             GENLIST=ALLOWED

RCAF Router Table EQQ9RF01. Use the following macro, which you can access in the EQQ9RF01 member of SEQQSAMP library:
```
     TAB18            ICHRFRTB  CLASS=TMEADMIN,ACTION=RACF
```

Using RCAF TMEADMIN class, map the administrator ID to the RACF user ID. The RACF user ID is associated with the administrator defined at the Tivoli® workstation. Any administrative action is thereby traceable to the user issuing the request.
Define a profile in the Tivoli-supplied resource class TMEADMIN for each administrator who is able to access Dynamic Workload Console.

Note:

In the following tasks, which are for mapping the administrator to RACF user IDs, it is recommended that each administrator maps to a unique RACF user ID.
Activate the TMEADMIN class by typing the following command: SETROPTS CLASSACT (TMEADMIN).
In the TMEADMIN class, use the following string to define a unique RACF user ID for each Tivoli administrator who will perform Dynamic Workload Console operations: userid@hostname. For example, for a user with the identifier SCOT at the host pelican you would use SCOT@pelican.
Enter the following command to define a general resource profile in the TMEADMIN class to associate the administrator with a RACF user ID (in this example, SCOT):
```
RDEFINE TMEADMIN SCOT@hostname APPLDATA('SCOT') 
```
Note:

The string SCOT@hostname is not case sensitive.
Refresh the TMEADMIN class with the following command:
```
SETROPTS RACLIST(TMEADMIN) REFRESH
```
If you experience problems using special characters to define a profile in the TMEADMIN class, use the following command instead:
```
SETROPTS GENERIC(TMEADMIN) REFRESH
```

Also, use the % sign instead of the special character. For example, for the Italian code page, the character @ (hex'B5') is not accepted by RACF. So, for SCOT@pelican, you should type SCOT%pelican.

When searching a list of TMEADMIN files for a match, RACF looks for the most similar generic profile.

Using a new server initialization parameter to associate a RACF user ID

Define a member in the file identified by the EQQPARM DD statement in the server startup job. This member contains all the associations between a z/OS controller user and a RACF user ID.

Set the USERMAP parameter in the SERVOPTS server initialization parameter to define the user name, as follows:
```
SERVOPTS
  SUBSYS(xxxx)
  USERMAP(USERS)
  PROTOCOL(E2E)
  PORTNUMBER(425)
```

Using the same approach as for the TMEADMIN class, check that the member USERS of the initialization parameter data set contain the following:

USER 'SCOT@PELICAN' RACFUSER(SCOT) RACFGROUP(GROUP1)
USER 'PAOLO@PELICAN' RACFUSER(FALSI) RACFGROUP(GROUP1)
USER 'MOSSOTT@PELICAN2' RACFUSER(FMOSSOTT) RACFGROUP(GROUP1)

The following table shows the relationship between security products and the security selections.

Table 24. Relationship between security products and security selections
Security Product used	Solution	Prerequisite
Security Server (RACF)	TMEADMIN	None (TMEADMIN class provided in z/OS base)
Other SAF-compliant	TMEADMIN	Manually define TMEADMIN class (using EQQ9RFDE and EQQ9RF01 samples)
All security products	ID mapping table

Permitting access to the controller through Dynamic Workload Console

If you use Dynamic Workload Console, you can control access to the controller through the security functions of both the z/OS connector and Tivoli Workload Scheduler for z/OS. Ensure that you consider both these environments when you update RACF.

User IDs involved with Dynamic Workload Console

The following example explains how the Tivoli administrator ID and the local user ID are related and used through Dynamic Workload Console:

The name of the host on which you run Dynamic Workload Console is Rome1
An administrator named ADMN1 is defined on Rome1
A local user LOCUSR1 is defined on Rome1
The administrator ADMN1 is associated with local user LOCUSR1
The controller identifies Dynamic Workload Console by means of the following user name:
```
USER ADMN1-AT-ROME1-domain RACFUSER (TSOuser) 
```
where TSOuser is the TSO user ID with which the Tivoli Workload Scheduler for z/OS dialog runs.

The WebSphere Application Server user identity

When the z/OS connector opens a connection with the Tivoli Workload Scheduler for z/OS server, the WebSphere® Application Server authenticates the communication by means of the WebSphere Application Server user identity. Depending on your configuration, the server user identity can be one of the following:

An automatically generated server identity that is not stored in a user repository (for example SERVER:TIPCELL_TIPNODE_SERVER1).
A server identity that is stored in the repository.

In either case you need to associate the server user identity to a RACF ID. You can modify your configuration to utilize the administrator ID as the server user identity by editing the changeSecurityproperty WebSphere Application Server tool (TWA_home/wastools or TWA_home\wastools) where you set UseRegistryServerId=true and you specify the administrator user ID and password in the ServerID and ServerPassword keys.