Security for TCP/IP connections

The scheduler authentication mechanism uses the SSL services of z/OS®. For further details, see z/OS Cryptographic |Services System Secure Sockets Layer Programming.

To enable SSL authentication for your network, perform the following |actions:

Create the SSL work directory by using the EQQPCS10 sample JCL. |You can use the same directory as the one used for SSL in E2E. In |the following examples, the directory is: /u/tws/ssl

From /u/tws/ssl/ as current directory, open a shell prompt, start |the gskkyman utility of z/OS Cryptographic Services System SSL, and do the |following: |
1. Create the keystore database and consider protecting it from unauthorized |access, because it has to contain private key and trusted certificates. |For example, consider the following database: /u/tws/ssl/TWS1.kdb.
2. Generate a password file and store it in the SSL directory defined |in the previous step, for example /u/tws/ssl/TWS1.sth.
3. At this point you can: |
  - Create a certificate request and send it to the Certificate Authority.
  - Store the signed certificate in the database.
  - Import the certificate of the Certification Authority which signed |your certificate.
  |
  In this way you have a database containing both your certificate |and Certification Authority's one.
  |
  The scheduler uses a |default name to identify your certificate; therefore you are not required |to set up a multiple database handling. If you need different certificates |in order to partition your network from a security point of view, |you need different databases. The advantage of this solution is that |you can store each database in a different directory, with its own |access list.

Configure IBM® Tivoli® Workload Scheduler for z/OS, by specifying the TCPOPTS |statement for each component of your network. Consider each component |according a client-server model. Typically, a client-server group |is composed by the trackers and data stores communicating with the |corresponding controller, or by a remote interface communicating with |the corresponding server. |
When the controller or the server started |task communicates with a partner component, the communication is always |started by the partner component; therefore the partner acts as a |client. Differently from the end-to-end communication, the communicating |partners use the same port numbers for both non-SSL and SSL communications.
|
Specify |the same TCPOPTS parameters for all the components in a client-server |group.
|
For a detailed description of the TCPOPTS statement, |see Customization and Tuning. The following |example shows a TCPOPTS definition to activate the SSL support.
|
|
```
 TCPOPTS 
|   . . .
|   SSLEVEL(FORCE)                           1 
|   SSLKEYSTORE('/u/tws/ssl/TWS1.kdb')       2 
|   SSLKEYSTOREPSW('/u/tws/ssl/TWS1.sth')    3 
|   SSLAUTHSTRING('OPCMASTER')               4 
|   SSLAUTHMODE(STRING)                      5 
```
|
In this example:
|
|
1
|
The FORCE keyword enables the SSL communication. |
|
2
|
TWS1.kdb is the database containing the certificate. |
|
3
|
TWS1.sth is the password file to access the database. |
|
4
|
OPCMASTER is the string defined as Common Name (CN) in the certificate. |
|
5
|
The STRING keyword enables the check on the CN string. |
|

When designing your configuration from a security point of view, |consider that:

To enforce your security, you can use the SSLAUTHMODE(STRING), |that requires to: |
- Create an SSL certificate for each controller started task. This |certificate will be used by the controller and its remote partners. |Define the certificate using as Common Name a unique string corresponding |to the controller.
- Create an SSL certificate for each server started task. This certificate |will be used by the server and its remote partners. Define the certificate |using as Common Name a unique string corresponding to the server.
|
The SSLAUTHSTRING must match the information contained in |the certificate sent by the partner. To verify it, you can use the gskkyman utility that allows displaying the keys |database and SSL certificate content. The certificate CN is returned |by gskkyman as the first line of the “Subject".

If you prefer to use SSLAUTHMODE(CAONLY), then you can use a single |SSL certificate for all your network.