Contents
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.
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:
-
IPv4 network addresses, for example
127.0.0.1
. -
IPv6 network addresses, for example
::1
. -
Simple host name, for example
myhost
. -
Fully Qualified Domain Names (FQDN), for example
myhost.acme.com
. -
Partially Qualified Domain Names (PQDN), for example
*.acme.com
. -
IPv4 Classless Inter-Domain Routing (CIDR) blocks, for example
192.168.2.0/24
.
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.
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”.
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" ] } }
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:
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.
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.
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.