Trusted Hosts

Trusted Hosts Introduction

All Spotfire 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. If the authentication request originates from a trusted host, the security service trusts the host-based authentication mechanism (e.g. UNIX login) on that host to have verified the identity of the user.

Caution

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 Trusted Hosts 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 Trusted Hosts.

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

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

You must set up Trusted Hosts configuration under two circumstances:

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

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

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

  • 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 Trusted Hosts 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.

The TrustedHosts object defines trusted hosts. Figure 1, “TrustedHosts relationships” shows the relationships to other configuration objects.

TrustedHosts relationships

TrustedHosts relationships

Multiple TrustedHosts configuration objects with different configuration names can be active at the same time. When a configuration is activated, all hosts in the new configuration are added to the trusted hosts for a node. When a configuration is deactivated, all hosts in the configuration being deactivated are removed from the trusted hosts for a node unless another active TrustedHosts configuration also defined the host as trusted.

A detailed description of the configuration object properties is in TrustedHosts object properties and a snippet for these properties is in Example 1, “TrustedHosts object snippet”.

Warning

IP addresses specified in the hosts configuration property must be quoted. See Example 1, “TrustedHosts object snippet”.

TrustedHosts object properties

Name Type Description
hosts String [ ] Trusted host names. Either a partially-qualified domain name, a fully-qualified domain name, a simple host name, an IPv4 or IPv6 address, or an IPv4 CIDR block. Optional. No default.

Example 1. TrustedHosts object snippet

name = "trusted-hosts"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"

configuration =
{
    TrustedHosts =
    {
        hosts =
        [
              "host1",
              "host2",
              "*.some.domain.org",
              "host4.tibco.com",
              "189.4.5.6",
              "192.168.2.0/24",
              "2601:646:4102:9184:d56c:b9bc:f9ed:1ee4%en1"
        ]
    }
}


Trusted Hosts Installation

When a node is installed all network interfaces are automatically added as trusted hosts. For example, a node may automatically have these network addresses added as trusted hosts:

epadmin --servicename=A.X display security --type=hosts
[A.X] Network Address = 0:0:0:0:0:0:0:1%lo0
[A.X] Host Name = localhost
[A.X] Source = default

[A.X] Network Address = fe80:0:0:0:0:0:0:1%lo0
[A.X] Host Name = localhost
[A.X] Source = default

[A.X] Network Address = 127.0.0.1
[A.X] Host Name = localhost
[A.X] Source = default
...

An example of using trusted hosts with epadmin is below. In this example host1 is a trusted host for the node running on host2. The username and password global parameters cannot be specified when using trusted hosts. Specifying the username and password parameters disables the trusted host mechanism and causes the epadmin command to use the standard authentication mechanism defined by the authentication realm.

//
//  Command executed on host1 and accessing a node on host2
//
epadmin --hostname=host2 --adminport=1234 display node

//
//   Command executed on host1 and accessing a node on host2
//
epadmin --servicename=A.X display node

When the display node command is executed on host1, the name of the user that executed the command is determined from the operating system. The user name is sent to the node on which the command is being executed (host2) and if the command came from a trusted host (host1), authentication succeeds.

Trusted hosts are defined using configuration (see epadmin-trusted(1) for details), as illustrated in the following example:

name = "trusted-hosts"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"

configuration =
{
    TrustedHosts =
    {
        hosts =
        [
              "host1",
              "host2",
              "*.some.domain.org",
              "host4.tibco.com",
              "189.4.5.6",
              "192.168.2.0/24",
              "2601:646:4102:9184:d56c:b9bc:f9ed:1ee4%en1"
        ]
    }
}

The example configuration defines these trusted hosts:

  • host1 — a simple host name.

  • host2 — another simple host name.

  • *.some.domain.org — a partially qualified domain name. Partially qualified domain names are indicated using a *. prefix. All hosts under the some.domain.org domain are trusted.

  • host4.tibco.com — a fully qualified domain name.

  • 189.4.5.6 — an IPv4 address.

  • 192.168.2.0/24 — an IPv4 CIDR block.

  • 2601:646:4102:9184:d56c:b9bc:f9ed:1ee4%en1 — an IPv6 address.

As mentioned above, the test for a trusted host is performed when an epadmin client connects to a node. The IP address of the client machine on which epadmin is executed is compared to the trusted host IP addresses. It is important to realize that the trusted host check is always done using IP addresses, not DNS names. The implications of this are as follows for each of the trusted host configuration types:

  • IPv4 and IPv6 network addresses are compared directly.

  • Simple host names, and fully qualified domain names, are resolved to an IP address when a configuration is activated. If the IP address of this simple host, or fully qualified domain name, changes after the configuration has been activated, the host is no longer trusted.

  • Partially qualified domain names are not resolved to an IP address when a configuration is activated. As clients connect to a node, if there is a configured partially qualified domain name, a reverse DNS lookup is done using their IP address to determine if the client is connecting from a host in the partially qualified domain name.

  • CIDR blocks configure a range of IP addresses to be trusted. As clients connect to a node, if there is a configured CIDR block, their IP address is algorithmically compared to the configured CIDR block.

Trusted hosts can be defined when a node is installed by specifying the trusted host configuration to install node as described in Overriding Default 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 = "com.tibco.ep.dtm.configuration.security"
configuration = {
  TrustedHosts = {
    hosts = [
      "able",
      "baker",
      "*.dept.example.com",
      "charlie.example.com",
      "192.0.2.42",
      "198.51.100.0/24",
      "2001:0db8:85a3:0000:0000:8a2e:0370:7334"
    ]
  }
}

Important

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.