What are the considerations setting requireClientAuthentication to "true" in SecureCommunicationClientProfile or SecureCommunicationServerProfile configuration?

requireClientAuthentication is used to set whether client requires a keystore

When connecting to a server securely, a client provides authentication credentials as either a username and password pair, or by supplying a certificate from a keystore. A keystore is a secure local file which contains a public key (the certificate) and a private key (which is never shared but only used locally to decrypt received messages). When requireClientAuthentication is "true" a client certificate must also be used to improve the security of the encrypted messages.

Using TLS communication, the initial connection handshake may require a certificate from:
A. the server (requireClientAuthentication = false), or
B. both the server and the client (requireClientAuthentication = true).

Option 'B.' is more strict. The client must have its own keystore and the certificate must be signed by a signing authority which the server has in its truststore. This option provides the server with the client's credentials through the Distinguished Name (DN) contained in the certificate for lookup in the server's configured Authentication Realm to determine roles and privileges so that the client does not have to provide username and password in separate configuration.

Option 'A.' allows the client to not have a keystore. The communication is still encrypted, but the user must instead provide username and password credentials. These credentials are used to determine that user's roles and privileges in the server's Authentication Realm.

The requireClientAuthentication setting must be set the same in both the server's SecureCommunicationClientProfile and the SecureCommunicationServerProfile. Note that these are both server-side configurations, and the SecureCommunicationClientProfile within the server determines the INTERNAL network communication settings when the server acts as a networked client to itself. External clients have their own configurations as appropriate for their implementation.

It is possible for the client to provide a certificate signed by a trusted authority and server to still require a separate username/password in the connection URL, but this is rarely seen. Signed certificates are assumed to be sufficiently secure.

An X509 certificate contains the user's Distinguished Name used in the LDAP or Local Authentication Realm configuration for role lookup. For example, the Distinguished Name is defined when creating a client key-pair using the Java keytool command. The keytool command asks for: 
  first and last name, 
  organization, 
  locality, 
  state/province, 
  and country code. 
The first and last name setting typically matches the user's email address or Common Name (CN), or all fields together match the DN.

A password does not appear in the certificate and its function is replaced by use of the server's Realm setting:
  allowSecureCommunicationClientAuthentication = true
which relies on the fact that the certificate is signed by a trusted signature authority. This setting only appears in the Local and LDAP configurations since OIDC and Kerberos "single sign on" authentication use their own mechanisms. If the allowSecureCommunicationClientAuthentication setting is false, then the client will have to provide a username and password separately in the connection URL (or prompted by the web browser). The values are sent encrypted since these values are passed after the TLS negotiation completes. The username and password values may be further encrypted by the server's master secret so they do not appear in plain-text within the URL.

When allowSecureCommunicationClientAuthentication is "false" the Streaming server obtains the user's memberships from LDAP using the user's supplied username and password. When using a Local Authentication Realm configuration, the username and password must match a user record created on the server using the administrative 'epadmin add user' command.

When allowSecureCommunicationClientAuthentication is "true" the Streaming server obtains the user's role from LDAP using the server's own LDAP credentials by proxy. It queries the memberships of the user using the DN values as lookup.

If using OIDC or Kerberos, the client certificate may still be used to secure the communication, but the username and password credentials are typically provided via a web-browser prompt on first access to any system that shares a single-sign-on session. This initial connection returns a session key which is then used for subsequent connections. This session key is passed back to the client encrypted so it cannot be copied and used by any other user.
 

The TIBCO Streaming documentation pages for this topic are:

• TIBCO Streaming > StreamBase Admin Guide > StreamBase Security Model > Secure Transport with TLS
• TIBCO Streaming > LiveView Admin Guide > Using TLS/SSL with LiveView Server
• TIBCO Streaming > Configuration Guide > Runtime Configuration Types > Runtime Security Configuration
• TIBCO Streaming > StreamBase References > Command Reference > sburi
• TIBCO Streaming > StreamBase References > Command Reference > lv-client
• TIBCO Streaming > StreamBase Admin Guide > StreamBase Security Model > Encrypting Sensitive Configuration Data