Since the connections between Symphony and its clients may be carrying sensitive information that is vulnerable to a security breach, there is a provision to safeguard the information by configuring the individual connections with SSL. Each connection can be configured independently and each server can implement a different authentication certificate. Note that Symphony DE does not support SSL configuration.
To better understand the implementation of SSL at Symphony startup, let’s look at the sequence of events.
The Service Controller starts the Session Director server as a service with its environment configured from its service definition file sd.xml. This file contains the SSL configuration for connections to the Symphony SDK client.
Upon startup, the Session Director listens on port SD_SDK_PORT for incoming connections from clients. The Session Director also registers with EGO as a client and uses its connection URL, <SD-hostname>:SD_SDK_PORT, as the client description. Note that SD_SDK_PORT is an environment variable defined in the sd.xml file.
The Symphony client opens a connection to EGO, which initiates SSL handshaking including server authentication, if so configured. EGO opens port EGO_KD_TS_PORT, which only accepts SSL connections. When transport security is set to SSL, client calls to the API use the EGO_KD_TS_PORT.
The Symphony client retrieves the connection URL to Session Director by passing the Session Director client name in an API call to EGO and retrieving the client description (connection URL).
The Session Director verifies the authentication information (e.g. name/password) and then starts an SSM server dedicated to the application. (The Session Director maintains an internal list with Application Profiles and starts the corresponding SSM as a service with its environment configured from sd.xml).
SSM finds the first available port and starts listening for clients. The SSM returns the URL as host:port to Session Director. Subsequent calls to the Session Director from new clients requesting an application that an SSM has already started will return the URL of the running SSM.
The Session Director sends the SSM’s URL and a user credential to the client. At this point, the client is able to use the connection to send tasks.