Security

Key and trust stores are supported both for node security and epadmin client security.

These key and trust store encoding types are supported on nodes and can be specified in secure communication profiles:

These key and trust store encoding types are supported by the epadmin client:

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.

Trusted hosts can be specified using:

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:

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.

All access through a web service endpoint must be authenticated using HTTP basic access authentication. This requires the HTTP user agent, for example a web browser, to provide a user name and password. The user name and password is authenticated by the authentication realm associated with the web service. By default, web service authentication uses the node administration realm. The authentication realm to use can be changed per web service using the WebServiceBinding configuration object (see WebServiceBinding) in a node deploy configuration. It is also possible to disable authentication for a web service using the WebServiceBinding configuration object.

As shown in Figure 4, “Web services authentication” web services authentication consists of these steps:

Web services authentication

Web services support the local (see Local Authentication Realm) and LDAP (see LDAP Authentication Realm) authentication realms with no support for trusted hosts. This implies that a valid username and password must always be provided when accessing a web service endpoint. The default user created when a node is installed (see Default Security) is not typically useful for accessing web service endpoints because the password is not known. Additional users should be added as required to support access to web service endpoints, for example, if a local authentication realm is being used, users should be added to the realm as described in epadmin add user.

There may be additional authentication required by the endpoint implementation. See Supported Web Services for details.

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 using Secure Shell (SSH) connections. SSH is a tool which provides authentication and confidentiality for network connections to remote hosts.

SSH is used when there is not a node coordinator running on the remote node. Specifically these epadmin commands use SSH when the global hostname parameter specifies a non-local host.

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

A Kerberos authentication realm supports Kerberos single signon authentication using one or more Kerberos Key Distribution Centers (KDC). Kerberos is only supported via the HTTP Simple and Protected [GSSAPI] NEGOtiation (SPNEGO) protocol; non-HTTP communication is not supported.

The Kerberos authentication realm only supports authentication, there is no support for authorization. To support authorization a fallback realm must be specified to provide authorization services.

A Kerberos authentication realm is configured using the KerberosAuthenticationRealm root configuration object. See Kerberos Authentication Realm.

An LDAP authentication realm performs authentication against a set of LDAP servers with potentially disjoint user populations. The realm supports any number of LDAP servers, each with different search properties, authentication mechanisms, and secure communication profiles. Multiple LDAP servers can be used for high availability (replicas of the same server), for unifying disjoint user communities, or both. When multiple LDAP servers are configured in a realm, they are tried in turn, always starting with the first server configured in the realm configuration, until a server responds with a positive authentication, or the request fails on all servers.

These mechanism are supported for authentication:

Support is also provided for:

An LDAP authentication realm is configured using the LDAPAuthenticationRealm root configuration object. See LDAP Authentication Realm.

The LDAP authentication realm can be used as the authentication realm for node administration. It can also function as a fallback realm.

All nodes support a native local authentication realm. This realm provides both authorization and authentication on a per-node basis. Users and their associated attributes are stored locally in a node's transactional memory. A cluster must have the same local authentication realm configuration and users defined to ensure a consistent security policy. Also all user level enforcement, for example password expiration and account locking, are done per node. So it is possible that a user may be locked out on one node, but can still can access other nodes in the cluster.

The local authentication realm supports these features:

There is also support for configuring a set of initial users that should be defined on the node allowing administrators to bulk-load users rather than creating them individually.

User administration is provided by the user administration target (see epadmin-user(1)) and password management is provided by the password target (see epadmin-password(1)). Support for backing up and restoring the local realm is provided by the realm administration target (see epadmin-realm(1)).

A local authentication realm is configured using the LocalAuthenticationRealm root configuration object. See Local Authentication Realm.

The local authentication realm can be used as the authentication realm for node administration. It can also function as a fallback realm.

An OpenId Connect (OIDC) realm uses a list of OIDC identity providers to perform single sign-on authentication. OIDC is only supported via the HTTP protocol; non-HTTP communication is not supported.

The OIDC authentication realm only supports authentication, there is no support for authorization. To support authorization a fallback realm must be specified to provide authorization services.

An OIDC authentication realm is configured using the OIDCAuthenticationRealm root configuration object. See OIDC Authentication Realm.

The security service supports a set of predefined roles that are used to grant privileges to principals.

The predefined roles are:

Each of these roles is described in more detail below.

Users are added to a node's local authentication realm using the Add Principal dialog accessed from the Add button.

The fields in the Add Principal dialog are:

Clicking on the Submit button will add the new user to the node after validating that the password values match.

Added users are never removed unless explicitly removed as described in epadmin remove user.

Users can also be added using:

epadmin --servicename=<node-service-name> add user \
   --username=admin --password=supersecret --roles=administrator

All principals defined in a local authentication realm on a node can be backed up using the Export Users dialog. This dialog is accessed from the Export button. The realm backup can be reloaded on a node using the restore realm administration command (see epadmin remove user).

The fields in the Export Users dialog are:

When the Submit button is clicked, the realm is backed up to the specified file. No sensitive information, such as passwords is visible in the exported file.

Local authentication realms can also be backed up using this command:

epadmin --servicename=<node-service-name> backup realm --name=default-realm > default-realm.backup

Local authentication realms can be restored using this command:

epadmin --servicename=<node-service-name> restore realm --name=default-realm \
    --file=/opt/backups/default-realm.backup

Passwords are changed in a local authentication realm using the Reset Password dialog accessed from the Reset button.

The fields in the Reset Password dialog are:

When the Submit button is clicked the password has been changed.

Passwords can also be changed using this command:

epadmin --servicename=<node-service-name> change password --realm=default-realm --username=admin

Users defined in a local authentication realm are removed from a node by selecting a principal in the Principals table and clicking on the Remove button.

When the Submit button is clicked the user has been removed.

Principals can also be removed using this command:

epadmin --servicename=<node-service-name> remove user --realm=default-realm --username=admin

User defined in a local authentication realm are updated using the Update Principal dialog accessed from the Update button.

The fields in the Update Principal dialog are:

The fields contain the current values for the user when the dialog is initially displayed. When the Submit button is clicked any changed values are updated for the user.

Users can also be updated using this command:

epadmin --servicename=<node-service-name> update user \
    --username=admin --roles=administrator

The authentication realm associated with node administration is set by default to a local authentication realm when a node is installed (see Default Security). The default node administration authentication realm cannot be changed using configuration. For example the following fails:

//
//    New configuration using an
//    authentication realm name of default-realm
//    (the default authentication realm name)
//
name = "my-local-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LocalAuthenticationRealm =
    {
        name = "default-realm"
        requirePassword = false
        initialPrincipals =
        [
            {
                userName = "guest"
                password = ""
                roles =
                [
                      "administrator"
                ]
            }
        ]
    }
}

//
//    Load configuration 
//
epadmin --servicename=A.X load configuration --source=realm.conf 
[A.X] type = com.tibco.ep.dtm.configuration.security
[A.X] name = my-local-authentication-realm
[A.X] version = 1.0.0

//
//   Activation fails because default local authentication realm
//   cannot be changed
//
epadmin --servicename=A.X activate configuration \
    --type=com.tibco.ep.dtm.configuration.security \
    --name=my-local-authentication-realm --version=1.0.0

[A.X] Audit failed: TIBCO-EP-DTM-00277: configuration (my-local-authentication-realm, 
com.tibco.ep.dtm.configuration.security, 1.0.0) contains an authentication realm with 
name "default-realm", which already exists in 
(default-realm-config, com.tibco.ep.dtm.configuration.security, 1.0.0)

However, it is possible to change the authentication realm associated with node administration to either a different local authentication realm or an LDAP authentication realm. Here are the required steps to change the node administration realm:

This example defines a single administration user named admin in a new local authentication realm and then updates node administration to use this new realm.

name = "my-local-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LocalAuthenticationRealm =
    {
        name = "my-local-authentication-realm"
        requirePassword = false
        initialPrincipals =
        [
            {
                userName = "admin"
                password = "admin"
                roles =
                [
                      "administrator"
                ]
            }
        ]
    }
}

//
//    Display the current node administration realm
//    This command is using the operating system
//    user that installed the node so no
//    user name or password is required from a trusted host
//
epadmin --servicename=A.X getadmin realm
[A.X] Realm Name = default-realm

//
//    Load the realm configuration
//
epadmin --servicename=A.X load configuration --source=realm.conf 
[A.X] type = com.tibco.ep.dtm.configuration.security
[A.X] name = my-local-authentication-realm
[A.X] version = 1.0.0

//
//    Activate the new realm configuration
//
epadmin --servicename=A.X activate configuration --type=com.tibco.ep.dtm.configuration.security \
    --name=my-local-authentication-realm --version=1.0.0

//
//   Set node administration to use this realm
//
epadmin --servicename=A.X setadmin realm --name=my-local-authentication-realm \
    --newrealmuser=admin --newrealmpassword=admin

//
//    Display the updated node administration realm
//    The new administrator user name and password must be 
//    specified since admin is not the operating system user
//    that installed the node.
//
epadmin --servicename=A.X --username=admin --password=admin getadmin realm
[A.X] Realm Name = my-local-authentication-realm

When changing the node administration realm the new realm must have at least one user defined with the administrator role to ensure that the node can be managed in the new realm. This is verified by the setadmin realm command by requiring the username and password of an administration user in the new realm.

Attempting to remove the last administration user in a local authentication realm is also prevented to ensure that a node can always by administered.

epadmin --servicename=A.X --username=admin --password=admin remove user \
    --realm=my-local-authentication-realm --username=admin
[A.X] Error: TIBCO-EP-DTM-00481: "admin" is the last remaining user in the realm and cannot be removed.

There are cases where administrators can unintentionally lock out all node administration users. Examples are:

There are two choices at this point:

To reset node authentication, the reset authentication command is executed on the same machine on which the node is installed. Operating system write access privileges to the node installation directory must be available to the user executing the command.

epadmin reset authentication --installpath=A.X

See epadmin-authentication(1) for more details.

Every administrative command is recorded in an audit log (see Logging). For each command executed the audit log reports on:

The KerberosAuthenticationRealm root configuration object defines Kerberos authentication for a node. There can only be a single KerberosAuthenticationRealm defined on a node.

name = "my.application"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.node"
configuration =
{
    NodeDeploy =
    {
        nodes = 
        {
            "A.X" =
            {
                communication =
                {
                    administration =
                    {
                        address = "myhost.com" // FQDN
                        webServiceBindings =
                        {
                            admin =
                            {
                                authenticationRealmName = "kerberos-realm"
                            }
                        }
                    }
                }
            } 
        }
    }
}

Figure 6, “KerberosAuthenticationRealm relationships” shows the relationships to other configuration objects.

KerberosAuthenticationRealm relationships

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

name = "kerberos-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    KerberosAuthenticationRealm =
    {
        name = "my-kerberos-authentication-realm"
        requireTrustedHostMembership = false
        fallbackAuthenticationRealmName = "my-local-realm"
        internalClientLoginConfigurationFile = "/opt/kerberos/client-configuration"
        internalClientKeytabFile = "/opt/kerberos/keytab/client"
        internalClientPrincipalName = "client-principal@ACME.COM"
        jaasDebug = false
        kerberosConfigurationFile = "/opt/kerberos/kerberos-configuration"
        serverKeytabFile = "/opt/kerberos/keytab/server"
        serverPrincipalName = "HTTP/my.host.com@ACME.COM"
        ticketCacheFile = "/opt/kerberos/ticket/cache/file"
    }
}

The LDAPAuthenticationRealm root configuration object defines LDAP integration for a node. Figure 7, “LDAPAuthenticationRealm relationships” shows the relationships to other configuration objects.

LDAPAuthenticationRealm relationships

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

name = "ldap-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LDAPAuthenticationRealm =
    {
        name = "my-ldap-authentication-realm"
        requireTrustedHostMembership = true
        allowSecureCommunicationClientAuthentication = true
        requirePassword = false
        servers =
        [
            { ... }
            { ... }
        ]
    }
}

The LDAPServer configuration object defines LDAP server configuration. Figure 8, “LDAPServer relationships” shows the relationships to other configuration objects.

LDAPServer relationships

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

name = "ldap-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LDAPAuthenticationRealm =
    {
        servers =
        [
            {
                host = "ldap.primary.acme.com"
                portNumber = 390
                principalAuthenticationAlgorithm = LOCAL_PASSWORD_COMPARE
                principalPasswordAttribute = "password"
                principalSearchRoots = [ "ou=users,dc=example.dc=com" ]
                principalSearchFilter = "cn={0}"
                roleSearchRoots = [ "ou=roles,dc=example.dc=com" ]
                roleSearchFilter = "membership={1}"
                roleNameAttribute = "roleID"
                secureCommunicationProfileName = "secure-ldap-client-profile"
                systemPassword = "secret"
                systemPrincipal = "cn=SBLDAPUser,cn=Users,dc=ldap,dc=example,dc=com"
            }
            {
                host = "ldap.backup.acme.com"
                portNumber = 390
                principalAuthenticationAlgorithm = LOCAL_PASSWORD_COMPARE
                principalPasswordAttribute = "password"
                principalSearchRoots = [ "ou=users,dc=example.dc=com" ]
                principalSearchFilter = "cn={0}"
                roleSearchRoots = [ "ou=roles,dc=example.dc=com" ]
                roleSearchFilter = "membership={1}"
                roleNameAttribute = "roleID"
                secureCommunicationProfileName = "secure-ldap-client-profile"
                systemPassword = "secret"
                systemPrincipal = "cn=SBLDAPUser,cn=Users,dc=ldap,dc=example,dc=com"
            }
        ]
    }
}

The LocalAuthenticationRealm root configuration object defines the characteristics and initial principals in the local authentication realm for a node. Figure 9, “LocalAuthenticationRealm relationships” shows the relationships to other configuration objects.

Changing the failedLoginLockoutDurationMinutes or failedLoginLockoutThreshold configuration properties by activating a new version of this configuration causes this behavior:

LocalAuthenticationRealm relationships

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

name = "local-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LocalAuthenticationRealm =
    {
        name = "my-local-authentication-realm"
        requireTrustedHostMembership = true
        allowSecureCommunicationClientAuthentication = true
        requirePassword = false
        failedLoginLockoutDurationMinutes = 5
        failedLoginLockoutThreshold = 3
        initialPrincipals =
        [
            { ... }
            { ... }
        ]
    }
}

The OIDCAuthenticationRealm root configuration object defines OpenId Connect authentication for a node. Figure 10, “OIDCAuthenticationRealm relationships” shows the relationships to other configuration objects.

OIDCAuthenticationRealm relationships

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

name = "oidc-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    OIDCAuthenticationRealm =
    {
        name = "my-oidc-authentication-realm"
        requireTrustedHostMembership = false
        defaultRedirectURL = "http://redirect.acme.com"
        fallbackAuthenticationRealmName = "my-ldap-realm"
        pendingAuthenticationTimeoutSeconds = 600
        identityProviders =
        {
            "Google" = { ... }
            "Auth0" = { ... }
        }
    }
}

The OIDCIdentityProvider object defines the configuration for OpenId Connect providers.

Support is provided for federated identity providers like Auth0. Federated providers use subject prefixes to map to the actual provider defined in this configuration. This mapping is configured using the subjectProviderMappings configuration property. For example:

//
//    Subject provider mappings in Auth0 configuration
//    A subject prefix of google-oauth2 maps to the 
//    configured "Google" identity provider
//
subjectProviderMappings =
{
    "google-oauth2" = "Google"
}

//
//    Auth0 identity contains "sub" claims
//
//    The "|" is the delimiter, so "google-oauth2" is the prefix that 
//    identifies the actual provider providing the identity information.
//    105569619522230371597 is the subject for the principal from the identity 
//    provider represented by google-oauth2
//
sub: 'google-oauth2|105569619522230371597'

//
//    The same principal authenticated directly against "Google"
//    would have the same identity information in the "sub" field.
//
sub: '105569619522230371597'

Figure 11, “OIDCIdentityProvider relationships” shows the relationships to other configuration objects.

OIDCIdentityProvider relationships

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

name = "oidc-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    OIDCAuthenticationRealm =
    {
        identityProviders =
        {
            "Google" =
            {
                documentDiscoveryURL = "https://accounts.google.com/.well-known/openid-configuration"
                clientID = "my-google-client-identifier"
                clientSecret = "my-google-client-secret"
                identityAttributeName = "email"
            }
            "Auth0" =
            {
                documentDiscoveryURL = "https://tibco.auth0.com/.well-known/openid-configuration"
                clientID = "my-auth0-client-identifier"
                clientSecret = "my-auth0-client-secret"
                identityAttributeName = "email"
                subjectProviderMappings =
                {
                    "google-oauth2" = "Google"
                }
            }
        }
    }
}

The Principal configuration object defines a principal managed by the local authentication realm. Figure 12, “Principal relationships” shows the relationships to other configuration objects.

Principal relationships

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

name = "local-authentication-realm"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    LocalAuthenticationRealm =
    {
        initialPrincipals =
        [
            {
                userName = "FredTheAdministrator"
                password = "LKJALISJDOIQUWEOIAJSLKDJALSJDL"
                roles =
                [
                      "administrator"
                ]
                passwordExpirationPeriodDays = 12
                locked = true
            }
        ]
    }
}

The RoleToPrivilegeMappings object defines the roles and their associated privileges. Figure 13, “RoleToPrivilegeMappings relationships” shows the relationships to other configuration objects.

RoleToPrivilegeMappings relationships

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

name = "my-target-role-mappings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    RoleToPrivilegeMappings =
    {
        privileges =
        {
            administrator = [ ... ]
            monitor = [ ...]
        }
    }
}

The Privilege object defines permissions for a resource. Figure 14, “Privilege relationships” shows the relationships to other configuration objects.

Privilege relationships

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

name = "my-target-role-mappings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    RoleToPrivilegeMappings =
    {
        privileges =
        {
            administrator =
            [
                {
                      resource = "mytarget.start"
                      privilege = "AdminRunCommand"
                },
                {
                      resource = "mytarget.stop"
                      privilege = "AdminRunCommand"
                }
            ]
            monitor = 
            [
                {
                      resource = "mytarget.display"
                      privilege = "AdminRunCommand"
                }
            ]
        }
    }
}

The SecureCommunicationClientProfile root configuration object defines a secure communication profile for client connectivity. Figure 15, “SecureCommunicationClientProfile relationships” shows the relationships to other configuration objects.

SecureCommunicationClientProfile relationships

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

name = "my-secure-client-settings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    SecureCommunicationClientProfile =
    {
        name = "my-secure-client-profile"
        keyStore = "/absolute/path/myKeyStore.jks"
        keyStorePassword = "secret"
        keyPassword = "anothersecret"
        keyStoreType = "jceks"
        trustStore = "/absolute/path/myTrustStore.jks"
        trustStorePassword = "athirdsecret"
        trustStoreType = "JCEKS"
        requireClientAuthentication = true
        excludedCipherSuitePatterns = [ "^.*_(MD5|SHA|SHA1)$" ]
        includedProtocols = [ ] // use JRE's supported protocols
    }
}

The SecureCommunicationServerProfile root configuration object defines a secure communication profile for listeners. Figure 16, “SecureCommunicationServerProfile relationships” shows the relationships to other configuration objects.

SecureCommunicationServerProfile relationships

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

name = "my-secure-server-settings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration =
{
    SecureCommunicationServerProfile =
    {
        name = "my-secure-server-profile"
        excludedCipherSuitePatterns = [ "^.*_(MD5|SHA|SHA1)$" ]
        includedProtocols = [ ] // use JRE's supported protocols
        keyPassword = "anothersecret"
        keyStorePassword = "secret"
        keyStore = "/absolute/path/myKeyStore.jks"
        keyStoreType = "jceks"
        requireClientAuthentication = true
        subjectNameElementToUserNameMappings =
        {   
            "subjectNameElementFoo" = "userNameFoo"
            "subjectNameElementBar" = "userNameBar"
        }
        trustStore = "/absolute/path/myTrustStore.jks"
        trustStorePassword = "athirdsecret"
        trustStoreType = "JCEKS"
        userNameObjectIdentifierSearchPath = [ "userID", "CN", "1.2.3.4", "DN" ]
    }
}

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

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 12, “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"
        ]
    }
}