SSL/TLS protected communication with RMF Distributed Data Server (DDS)

This topic shows an exemplary setup that the communication with RMF Distribution Data Server (DDS) is protected. After the configuration, the CIM server establishes an encrypted connection with DDS. Whether a trusted relationship is established or not depends on the DDS configuration. In this trusted relationship, DDS is the server, an inbound policy needs to be specified. For more information, see Setting up secure communication for the Distributed Data Server in . The CIM server is a client to the DDS and an outbound policy need to be specified with AT-TLS.

Sample Policy Agent policy for communication with DDS protection:

TTLSRule              CFZCIMDDAClientRule
{
   Jobname                  CFZCIM*
   RemotePortRange          8803
   RemoteAddr               9.xxx.yyy.zzz
   Direction                Outbound
   TTLSGroupActionRef       grp_StartUp
   TTLSEnvironmentActionRef CFZCIMDDSClientENV
}

TTLSEnvironmentAction CFZCIMDDSClientENV
{
  HandshakeRole        Client
  TTLSKeyRingParms
  {
    Keyring  CFZCIMClientKeyRing
  }
}

# Common StartUp Group that new Rules may use
# Shows how each connection maps to policy
TTLSGroupAction grp_StartUp
{
 TTLSEnabled On
 Trace 0             
}

CIM server specific notes to the AT-TLS Policy parameters:

TTLSRule: Jobname: Jobname identifies where this rule applies. In this example it is the started task job name. If you set up the connection this way, the configuration does not influence other parts of the system.
TTLSRule: RemoteAddr: RemoteAddr specifies the remote IP address this rule applies. In the example, it is the IP address of the remote RMF DDS server (9.xxx.yyy.zzz).
TTLSRule: RemotePortRange: RemotePortRange specifies the port of the remote RMF DDS server (8803).
TTLSKeyringParms: Keyring: Keyring specifies the key ring of the user ID that connects to DDS. The CIM server uses thread-level security. It is the user ID that generates the request connected to DDS (CFZCIMClientKeyring). It is not the key ring of the CIM server user ID. (9.xxx.yyy.zzz).

Note: If there are multiple user IDs that need to generate a request to the CIM server and connect to DDS, the TTLSRule needs to be set up for each user ID. For convenience, a virtual key ring can be specified in place of a real key ring to simplify the configuration. For details, see RACF and key rings in z/OS Security Server RACF Security Administrator's Guide.