Secure Transport with TLS

StreamBase supports transport secured with TLS:

You configure secure transport with a secure communication profile in a HOCON configuration file. There are two kinds of profiles: client profiles secure the client side of a network connection, while server profiles secure the server side of a network connection.

Each profile has a unique name. Attempts to activate a configuration containing a profile with the same name as an existing profile fails if the profile is of the same client or server type. You can update profiles with the same name and same type.

A client profile configuration is specified in a SecureCommunicationClientProfile root object of the security configuration type. Client profiles are currently used for the following purposes:

Client profiles require the following information:

If the profile enables client (mutual) authentication, then it must also contain:

Profiles that reference key and/or trust store files that do not exist on the machine where the node is installed fail to activate.

Client profiles also permit tuning of the secure transport protocol and the cipher suites used by that protocol. You can include specific protocols and/or cipher suites. The client then negotiates with the server endpoint using only those values. You can also exclude specific patterns of protocol and/or cipher suite. The client then starts with its Java system defaults for those values and removes any that match a pattern before beginning negotiation with the server endpoint. The include and exclude values are mutually exclusive. If you do not provide include or exclude values for cipher suites, the security infrastructure uses a default exclude value that prevents cipher suites that are known to have security flaws from being used during negotiation.

A server profile configuration is specified in a SecureCommunicationServerProfile root object of the security configuration type. Server profiles are currently used for the following purposes:

Server profiles require the following information:

If the profile enables client (mutual) authentication, then it must also contain:

Profiles with key and/or trust store files that do not exist on the machine where the node is installed fail to activate.

Server profiles also support tuning of the secure transport protocol and the cipher suites used by that protocol. You can include specific protocols and/or cipher suites. The server then negotiates with the client endpoint using only those values. You can also exclude specific patterns of protocol and/or cipher suite. The server then starts with its Java system defaults for those values and removes any that match a pattern before beginning negotiation with the client endpoint. The include and exclude values are mutually exclusive. If no include or exclude values are provided for cipher suites, the security infrastructure uses a default exclude value that prevents cipher suites that are known to have security flaws from being used during negotiation.

Server communication profiles provide the ability to translate incoming client X.509 certificate subject Distinguished Names (DNs) into user names for preauthentication using TLS client (mutual) authentication. Some authentication realms support this functionality and bypass authentication if a preauthenticated authentication token is provided to them.

Server profiles also provide the ability for internal clients to override the host name in the URL that they use to connect to themselves, so it matches a server SAN in the server's X.509 certificate.

Secure EventFlow engine API communication is enabled by activating a ClientAPIListener root object of the sbclientapilistener configuration type. This configuration must contain a secureCommunicationProfileName property whose value is the name of a secure communication server profile. That profile's configuration file must be activated before the listener's configuration, or the reference to the profile fails to resolve, and the activation attempt fails.

Secure LiveView engine API communication is enabled by activating a ClientAPIListener root object of the ldmclientapilistener configuration type. That configuration must contain a secureCommunicationProfileName property whose value is the name of a secure communication server profile. That profile's configuration file must be activated before the listener's configuration, or the reference to the profile fails to resolve and the activation attempt fails.

Secure internal LiveView client communication is enabled by activating an InternalCredentials root object of the ldminternalcredentials configuration type. That configuration must contains an ldmSecureInternalCommunicationProfileName property whose value is the name of a secure communication client profile. That profile's configuration file must be activated before the internal credential configuration, or the reference to the profile fails to resolve and the activation attempt fails.

Secure LDAP communication is enabled by activating an LDAPAuthentication root object of configuration type security that contains a secureCommunicationProfileName property whose value is the name of a secure communication client profile. That profile's configuration file must be activated before the LDAP realm configuration, or the reference to the profile fails to resolve and the activation attempt fails.

Once a profile is referenced by one or more configurations, it cannot be deactivated. If you want to deactivate and remove a profile referenced by other configurations, you must deactivate the referencing configurations first.