User authentication

User authentication
Prev	Chapter 5. Security	Next

Authentication is based on authentication realms associated with users. A user is uniquely identified by a user name, and has a set of attributes. These attributes include:

Authentication Realm - Authentication realm in which user is defined.
User Name - Unique identifier for this user.
Password - Credential for this user.
Roles - One or more roles granting privileges to this user.
Password Expiration - The duration in days that the password is valid.
Trusted Hosts Only - Allow access only from trusted hosts, or from any host (defined by authentication realm).
Password Required - Define whether a password is always required, or only from untrusted hosts (defined by authentication realm).
Automatic Secure Communication Authentication - Define whether a user is automatically authenticated without a password when connecting over a secure (e.g. TLS) communication channel (defined by authentication realm).

These attributes are defined using administrative commands, or loading and activating configuration files.

See the section called “Add user” for details on how a user is defined.

Authentication verifies that a given user is valid and that the presented password matches the password defined for the user. The presented password is validated using the mechanism defined by the authentication realm. Once authentication succeeds, all work done in the context of the current administration command will be done in an authenticated session for that user. Any access to secured resources during that session will require that the user was granted a role which has access privileges for the resource. User definitions may be updated, for example to change the password, or the set of granted roles. See the section called “Update a user” for details on how to update an existing user definition.

Trusted hosts

All authentication realms support configuration of trusted hosts, which allows authentication to occur without providing a user name and password. 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.


	As implied by the name, 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 general company wide private networks, and it should be disabled.

Trusted hosts can be specified using:

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 and IPv6 Classless Inter-Domain Routing (CIDR) blocks, for example 192.168.2.0/24 or 201:db8::30:4/101.

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 the section called “TrustedHosts” 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",
              "201:db8::30:4/101",
              "2601:646:4102:9184:d56c:b9bc:f9ed:1ee4%en1"
        ]
    }
}

This 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.
201:db8::30:4/101 - an IPv6 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.

Secure shell (SSH)

The epadmin command-line tool provides administrative access to nodes running on both local and remote hosts. Some commands sent to nodes running on remote hosts are executed via Secure Shell (SSH) connections. SSH is a tool which provides authentication and confidentiality for network connections to remote hosts.

SSH requires configuration of authentication keys for the user who executes the remote request. Authentication keys for SSH are generated using the ssh-keygen command-line tool. See the ssh-keygen manual page (run man ssh-keygen on a Unix host) for further information on how to generate authentication keys, and where the keys must be stored for SSH to make use of them.

Prev	Up	Next
Secure communication profiles	Home	Authentication realms