Security Features

TIBCO FTL software includes the following security features:

  • The choice of user-defined TLS certificates or TLS certificates generated by FTL.

  • TLS for communication among applications and FTL servers.

  • HTTPS for secure access to the administrative user interface and REST API.

  • A choice of various built-in and customizable authentication mechanisms.

  • Coarse separation of users into three categories, application clients, servers, and administrators.

  • Fine-grained permissions for persistence clusters and eFTL channels.

  • Full configuration control
  • Monitoring and logging

Security Boundaries

FTL logs key activities. Your organization is responsible for protecting and reviewing those files.

FTL ensures that administrative interfaces properly authenticate and authorize users. Your organization is responsible for configuring permissions for those users.

Your organization is responsible for making sure that the running engines have sufficient resources to handle the loads created by the applications.

The OWASP Top 10 document and the CWE Top 25 Most Dangerous Software Weaknesses can help your organization ensure that the most critical security risks are covered.

Security Vulnerabilities

Security features that protect FTL connections and communications depend on the implementation of OpenSSL for implementation Transport Layer Security (TLS) protocols. If the security of OpenSSL were compromised, FTL and applications that use FTL could be vulnerable as well.

For information about OpenSSL configuration, components, and downloads, see OpenSSL.org.

In addition to the key security technologies described, security depends on your organization correctly configuring and using FTL's components and capabilities.

Password Security

Keystore passwords encrypt key files, such as the private key file that FTL servers use to identify themselves to clients and to other servers.

Passwords can be masked. You can mask passwords using tibftladmin. Masked passwords have $mask$ at the beginning of the string. Masked passwords are unmasked before being sent to the realm service.

FTL allows you to supply a password in several ways based on the level of security desired.

For details, see "Password Security", "Security: Clients" section in TIBCO Administration.

Authentication

Administrators can configure the FTL server to require authentication for connections from clients and other FTL servers. When authentication is enabled, administrators can optionally enable authentication for specific FTL services, such as the persistence service or the eFTL service, or for peer-to-peer FTL transports. For details, see “Securing Persistence Services” and “Securing eFTL Services”.

FTL server can be configured to use one or more of the following authentication providers:

  • Built-in “flat-file” authentication

  • Built-in ldap authentication

  • Built-in oauth2 authentication

  • Built-in mTLS authentication (also requires TLS)

  • Customizable authentication to a user-provided HTTP(S) service (for example, a user-provided service that implements JAAS)

For details, see Authentication

At a minimum, the administrator must assign users to one of three categories and configure the authentication provider accordingly:

  • Clients have the “ftl” role, which allows them to connect to FTL server or other FTL clients.

  • Servers have the “ftl-internal” role, which identifies them as fully privileged servers when connecting to other FTL servers.

  • Administrators have the “ftl-admin” role, which identifies them as administrators to the FTL server for the purpose of monitoring and making configuration changes.

    For details, see FTL Server Authorization Groups

TLS

Administrators can configure the FTL server to require TLS for connections from clients and other FTL servers. When enabled, any connection that requires authentication will also require TLS. Authentication is always required to use TLS. See Authentication for an overview.

Administrators can configure TLS in one of two ways:

  • FTL-generated certificates: TLS certificates are generated by FTL server. This is required when enabling TLS and authentication for peer-to-peer FTL transports or transport bridges.

  • User-defined certificates: TLS certificates are provided by the administrator. This allows the administrator to have full control over the use of TLS certificates in FTL. This is required for mTLS authentication.

For details, see Enabling TLS for FTL Server

In addition, for situations where TLS termination occurs at an ingress point (before the connection reaches FTL server), it is possible to enable TLS only at the client. In this case, for all connections that require authentication, the client will also use TLS. For these same connections, FTL server will require authentication, but not TLS.

Permissions

In addition to authentication, administrators can additionally enable fine-grained permissions to control which users can send or receive messages. Various permissions may be configured for persistence clusters, persistence stores, or eFTL channels. For details, see Authorization

To use permissions, authentication must be enabled for FTL server and the affected persistence services or eFTL services. TLS may optionally be enabled at FTL server and the client, or just at the client.