Considerations when using inter-daemon system authentication

Before enabling inter-daemon system authentication, take into account these considerations.

Security performance and scalability considerations

When data privacy and integrity using TLS is configured for security, application data between the client and the SSM, the SSM and the SIM, and the client and the SI are encrypted and digitally signed. Because of additional processing power required to encrypt or decrypt data, and generate or verify digital signatures, performance will generally degrade. Three factors can affect the level of degradation:

Scale: The number of computing slots for the application.
Application data size: This factor includes task input and output, and common data.
Strength of the cryptographic algorithm: When security is enabled, the default TLS cipher suite is used, which optimizes performance and provides data privacy and integrity requirements.

Performance might be observed through different means, such as through workload bandwidth and latency, CPU and slots utilization.

From simulation test results, using various application patterns, performance degradation typically ranges from 30% to 60% when Common Data Optimization (CDO) is enabled. When CDO is disabled, performance degrades because more data requires TLS processing. In the case of a short workload pattern, the time required for establishing a secure connection will dominate, so relative performance will degrade more significantly. For components where more data is processed, this may increase CPU usage (for example, for SSM and the application client).

TLS also requires additional processing power, and hence, affects scalability. For example, while establishing a network connection, there is more metadata exchanged to build up the security context, which requires a longer time to connect (compared to the timeframe for a non-TLS case). To accommodate this, increase the following connection timeout and retry configuration settings:

Configuration source	Where to use	Syntax	Description	Default value	Increase to this value
startUpTimeout	SOAM > SIM section of the application profile	`<SIM startupTime out="1800"></SIM>`	Number of seconds to wait for the service instance manager to start up before the session manager considers it as timed out.	60	1200
SOAM_DIRECT_DATA_CONNECTION_RETRY_LIMIT	SOAM > Service > osTypes > osType > env section of the application profile	`<env name="SOAM_DIRECT_DATA_CONNECTION_RETRY_LIMIT">10</env>`	Specifies the number of attempts made by SI to reconnect to client.	0	10
SOAM_DIRECT _DATA_CONNECTION_RETRY _INTERVAL	SOAM > Service > osTypes > osType > env section of the application profile	`<env name="SOAM_DIRECT_DATA_CONNECTION_RETRY_INTERVAL">5</env>`	Specifies how long the SI waits in seconds before the next attempt to reconnect to the client.	1	10

Whenever possible, design applications to use a smaller number of slots. This minimizes the that impact to scalability.

Interacting with existing security configuration in sd.xml

In both the sd.xml file and the application profile, you can define the same parameters (for example, both can configure the SDK_TRANSPORT_ARG or SSM_SDK_TRANSPORT_ARG parameters). However, the values from the application profile overrides the values defined in the sd.xml file, and then the values are passed to SSM. Therefore:

Use the sd.xml file to configure cluster-wide TLS configurations.
Use the application profile to customize the TLS configuration for different applications.

Note: When the value of the SDK_TRANSPORT_ARG parameter in the application profile overrides the value defined in the sd.xml file, it override the SSM and client's TLS connection; it does not override the SOAM session director and client's TLS connection.

Backward compatibility of secure connection between the client and SD or SSM

Instead of using the security parameters configured in sd.xml or the application profile, the client can also use local TLS configuration. If the client configures the environment variable SSL_COMPATIBILITY_MODE=N, the client uses the security parameters in EGO_CLIENT_TS_PARAMS defined in the local ego.conf file.

Backward compatibility of secure connection between the SOAM session director and SSM

Set the SD_SSM_SSL_COMPATIBILITY_MODE environment variable within the sd.xml file to enable or disable backward compatibility of the TLS connection between SD and SSM. By default, backward compatibility is set (SD_SSM_SSL_COMPATIBILITY_MODE=Y).

The SSM normally connects to the SOAM session director. When the SOAM session director restarts, it connects back to the running SSMs:

Behavior when backward compatibility is disabled (SD_SSM_SSL_COMPATIBILITY_MODE=N)

The SOAM session director uses SD_SDK_TRANSPORT and SD_SDK_TRANSPORT_ARG when creating the listening port for SSM
SSM uses SD_SDK_TRANSPORT and SD_SDK_TRANSPORT_ARG when creating the listening port for SD
The SOAM session director uses SD_SDK_TRANSPORT and SDK_TRANSPORT_ARG when connecting to SSM
SSM uses SD_SDK_TRANSPORT and SDK_TRANSPORT_ARG when connecting to the SOAM session director

The SOAM session director uses SD_SDK_TRANSPORT and SD_SDK_TRANSPORT_ARG when creating the listening port for the client.

The SSM uses SD_SDK_TRANSPORT and SD_SDK_TRANSPORT_ARG when creating the listening port for the client.

Behavior when backward compatibility is enabled (SD_SSM_SSL_COMPATIBILITY_MODE=Y

The SOAM session director uses SSM_SDK_TRANSPORT and SSM_SDK_TRANSPORT_ARG when creating the listening port for SSM
SSM uses SSM_SDK_TRANSPORT and SSM_SDK_TRANSPORT_ARG when creating the listening port for the SOAM session director
The SOAM session director uses SSM_SDK_TRANSPORT and SDK_TRANSPORT_ARG when connecting to SSM
SSM uses SSM_SDK_TRANSPORT and SDK_TRANSPORT_ARG when connecting to the SOAM session director

The SOAM session director uses SD_SDK_TRANSPORT and SD_SDK_TRANSPORT_ARG when creating the listening port for the client.

The SSM uses SSM_SDK_TRANSPORT and SSM_SDK_TRANSPORT_ARG when creating the listening port for the client.

If backward compatibility of the TLS connection between the SOAM session director and SSM is enabled, then SDK_TRANSPORT_ARG must contain CAFILE or CAPATH, SERVER_AUTH, CERTIFICATE, and PRIVATE_KEY.

Reserved names for the SOAM session director and SSM in SERVER_AUTH

When the IBM® Spectrum Symphony client specifies the SERVER_AUTH parameter in the TLS configuration, the client will verify the CN (common name) in the daemon’s certificate. For example, if SERVER_AUTH=vemkd{Platform vemkd}egosc{Platform Service Controller}, the client will check the VEMKD certificate’s common name against Platform vemkd, and the EGOSC certificate’s common name against Platform Service Controller.

Notes:

The reserved name in SERVER_AUTH for the SOAM session director is sd, and for SSM, it is the application name. For example, if SERVER_AUTH={Symphony Daemons}sd{Platform Service Director}symping732{Platform Symping}, the client of Symping732 will check the SD against Platform Service Director, and check the SSM against Platform Symping and other daemons against Symphony Daemons.
The CN of the TLS certificate should not contain braces (such as { or }). For example, a CN of {test} is not valid, but simply test is.

Configuring authentication using SERVER_AUTH

When configuring authentication for EGO daemons by editing the ego.conf file, ensure that the SERVER_AUTH parameter is set, and that it does not have a value of NONE. No value defaults to NONE, so that the client does not verify the server's certificate.

For SOAM daemons, if the SERVER_AUTH parameter is not defined or is set to NONE, the client will still verify the server's certificate, but will ignore the common name in the certificate.