Secure Transport with TLS

Overview

StreamBase supports transport secured with TLS:

  • All communication between a node management client, including epadmin, and the node always uses TLS and is not configurable.

  • Client-server communication with the EventFlow and LiveView engines can be optionally secured with TLS and is configurable.

  • Communication between an LDAP authentication realm's LDAP client and an LDAP server can also optionally be secured with TLS, and is also configurable.

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.

Client Profiles

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:

  • Securing an LDAP connection from an LDAP authentication realm's LDAP client to an LDAP server.

  • Securing internal LiveView connections — that is, connections made from a LiveView engine to the same or other LiveView engines. A secure client profile for internal use is allowed only if the engine's listener enables secure transport, in which case it is required. If the LiveView engine listener uses secure transport with client (mutual) authentication, then the client profile must also enable client authentication, must have a keystore and password, and the server profile must have a trust store and password.

Client profiles require the following information:

  • Trust store file — this file must exist on the machine where the node is installed.

  • Trust store password.

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

  • Keystore file — this file must exist on the machine where the node is installed.

  • Keystore password.

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.

Server Profiles

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:

  • Securing an EventFlow engine API listener.

  • Securing a LiveView engine API listener. If the LiveView engine listener uses secure transport with client (mutual) authentication, the server profile must have:

    • A trust store and password.

    • The LiveView engine internal credentials configuration must be active and must specify a secure communication client profile.

    • The client profile must contain a keystore and password, and enable client authentication.

  • Securing communications for the node's administration, distribution, node-to-node connections, and REST API listeners. The server profile must have:

    • A trust store and password; when used for node-to-node connections, the truststore is required to validate the certificates sent by the other nodes in the cluster.

Server profiles require the following information:

  • Keystore file — this file must exist on the machine where the node is installed.

  • Keystore password.

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

  • Trust store file — this file must exist on the machine where the node is installed.

  • Trust store password.

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.

Referencing Secure Communication Profiles

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.