Trusted Hosts

Trusted Hosts Introduction

All TIBCO Streaming security realms support the notion of trusted hosts. By default, if no user ID is specified, the currently logged-in system user ID is used. Authentication credentials (in realms that use them) are not required when a request originates from a trusted host and the requester does not provide a user ID (thereby defaulting to the current system username). Realms can override this behavior.


The trusted hosts mechanism should only be used on tightly controlled private operational networks. The integrity of the trusted host mechanism relies on the access control and auditing of the host operating system. The trusted hosts mechanism is not appropriate for public networks, or for general company-wide private networks, where it should be disabled.

You can specify a list of trusted hosts as part of the node's initial configuration, and you can later update the trusted host list with an epadmin command to a running node.

See Default Security Configuration to understand how a TrustedHosts configuration works in conjunction with the security system defaults.

Trusted Hosts Configuration

Specify the node's initial trusted host list with a configuration file of type security with root object TrustedHosts.

The node's host machine is always trusted by default, so you do not need to specify localhost, or or ::1.

Provide a comma-separated list of hosts in any of the following formats:

  • Simple host names

  • Fully qualified domain names

  • Partially qualified domain names

  • IPv4 single addresses

  • IPv6 single addresses

  • CIDR blocks of IPv4 addresses

You must set up Trusted Hostsconfiguration under two circumstances:

  • For a cluster of more than one LiveView server, so that the service layer cancommunicate with the data layer.

  • If configured for peer recovery, so that peer data layers can communicate witheach other.

This is true for all security realms. Make sure your realm's configuration file has thesesettings:

  • requireTrustedHostMembership = true

  • requirePassword = false

Remember that HOCON parameter value strings that contain a period must be quoted. This includes domain name and IP address strings.

Add the TrustedHosts configuration file to the src/main/configurations folder of the target node's Studio project and restart the node (or upload and activate the configuration, if the node is already running).

Edit the configuration to include addresses for all the remote hosts you expect to connect from. That is, to run a node on host Able, but connect to that node from Baker, you must configure Baker's network name or IP address in the configuration file for the module that is to run on host Able. Then restart the node on Able or upload and activate the configuration.

Loading and Activating Configuration

After the node is installed and running, you can use epadmin load configuration to load a new TrustedHosts configuration file. You can then deactivate the current configuration and activate the new one. See epadmin-configuration for assistance. Be sure to increment the version property of your successive configuration files to more easily distinguish which one to keep active.

There can be only one active trusted host configuration per node, although there can be multiple independent TrustedHosts configuration files within the node.

Even when switched to an enterprise-level realm such as LDAP or OIDC that requires and manages credentials for each user, you can still require node connections to originate from a trusted host. This adds whitelist security on top of the realm's authentication security to further narrow the range of authorized users.

Trusted Hosts Configuration Example

name = "trustedhosts"
version = "1.0.0"
type = ""
configuration = {
  TrustedHosts = {
    hosts = [


Do not configure a trusted host configuration for your service layer fragment without a thorough security review. In general, make these settings only for your data layer fragments.