Using TLS/SSL with LiveView Server

Use a HOCON configuration file of type ldmclientapilistener to define and name this authentication realm and to set the port one which the TLS-enabled server listens for connections. The traditional TLS port for LiveView is 10443. This file also identifies the client profile to use.

For example:

name = "enableTLS"
version = "1.0.0"
type = "com.tibco.ep.ldm.configuration.ldmclientapilistener"
configuration = {
  ClientAPIListener = {
    portNumber = 10443    
    authenticationRealmName = "authRealm"
    secureCommunicationProfileName = "TLSclient"
  }
}

The secure communication client profile is used when setting the ldmSecureInternalCommunicationProfileName property in LiveView Internal Credentials Configuration file or the secureCommunicationProfileName property in LiveView Client API Listener Configuration file.

Use a configuration file of HOCON type security with root object SecureCommunicationClientProfile to identify the keystore file and its password. Each profile has a unique name across all server and client profile types. The name serves as a reference target from other configurations wishing to enable secure communication.

The following is a sample that configures a secure communication profile for a client endpoint. A secure communication profile configuration object contains settings used to secure client-side transport connections (for example, to external services such as LDAP). Profiles are named and then referenced as needed by other configurations needing secure communication.

For example:

name = "TLSclientsettings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration = {
  SecureCommunicationClientProfile = {
    name = "TLSclient"
    keyStore = "/absolute/path/to/myKeyStore.jks"
    keyStorePassword = "secret"
    keyPassword = "anothersecret"
    keyStoreType = "JKS"
    trustStore = "/absolute/path/to/myTrustStore.jks"
    trustStorePassword = "athirdsecret"
    trustStoreType = "JKS"
    requireClientAuthentication = false
  }
}

The server profile is for the API listener in your LiveView server. For TLS with client certificate authentication, the profile contains a trust store used to validate incoming server certificates.

If you enable TLS on a LiveView server, you need both the SecureCommunicationClientProfile and the SecureCommunicationServerProfile configured. This is due to the server and client certificates having different attributes, and CAs do not issue a single certificate appropriate for both client and server use.

For example:

name = "TLSserversettings"
version = "1.0.0"
type = "com.tibco.ep.dtm.configuration.security"
configuration = {
  SecureCommunicationServerProfile = {
    name = "TLSserver"
    keyStore = "/absolute/path/myKeyStore.jks"
    keyStorePassword = "secret"
    keyPassword = "anothersecret"
    keyStoreType = "JKS"
    trustStore = "/absolute/path/myTrustStore.jks"
    trustStorePassword = "athirdsecret"
    trustStoreType = "JKS"
    requireClientAuthentication = false
    userNameObjectIdentifierSearchPath = [ "userID", "CN", "1.2.3.4", "DN" ]
  }
}

The default SecureCommunicationServerProfile contains a excludedCipherSuitePatterns property that excludes the cipher suites.

excludedCipherSuitePatterns = [ "^SSL_.*$","^.*DH_.*$","^.*KRB5.*$","^.*NULL.*$","^.
  *anon.*$","^.*DES.*$","^.*MD5$","^.*DSS.*$","^TLS_RSA(?:(?!_WITH_AES_128_CBC_SHA).)
  *$"]

Use a configuration file of HOCON type ldmengine to specify the name of the server as expected in the DN field of the certificate, using the liveview.ssl.hostname system property.

The certificate used by your server is selected automatically based on the server's hostname. Use this system property if you get errors trying to find the certificate for your hostname, such as when the hostname that the LiveView server tried to find is incorrect.

For example:

name= "ldmengine-security"
version= "1.0.0"
type= "com.tibco.ep.ldm.configuration.ldmengine"

configuration = {
  LDMEngine = {
    systemProperties = {
      "liveview.ssl.hostname" = "lvserver201.example.com" 
    }
    ...
  }
}

To connect to a LiveView server using TLS, LiveView clients use URIs with a protocol of lvs instead of lv. When configured for TLS, a LiveView server listens on the port specified in the ldmclientapilistener file, which is traditionally 10443 for LiveView server TLS. This is also the default port of a LiveView URI when using the lvs protocol. You can override the default LiveView TLS port by adding an explicit port number to the URI, for example:

lvs://myusername:myPassword@localhost:10888

When connecting to LiveView through TLS, the LiveView client and server perform an TLS handshake, which includes the server sending its certificate to the client. If the client is not configured to trust the server's certificate, the handshake fails and the connection is not established.

For Java-based LiveView clients (including Spotfire LiveView Workspace Manager, the lv-client command, and any custom Java client application your organization writes with the LiveView Java Client API), the trust relationship can be configured by setting the trustStore and trustStorePassword properties in the SecureCommunicationClientProfile root object for the security configuration type for the JVM that runs the client.

The following is an example of using an environment variable to set the required system property settings for LiveView clients such as lv-client that honor environment variables. The actual setting of this variable is dependent on your platform.

LIVEVIEW_CLIENT_JVM_ARGS="-Djavax.net.ssl.trustStore=/Users/sbuser/sitetruststore.jks \
  -Djavax.net.ssl.trustStorePassword=secret1ve" 

Configuring the trust relationship for non-Java LiveView clients is beyond the scope of this document.

If you are connecting to a TLS-enabled LiveView server with .NET 4.5 or lower, be advised the default TLS options are incompatible with LiveView. LiveView only supports only TLS 1.1 and later and does not support the insecure TLS 1.0 or earlier versions.

The default for .NET 4.5 and earlier is only TLS 1.0. To enable TLS 1.1 or 1.2 for your .NET client, you must do one one of the following:

The userNameObjectIdentifierSearchPath property attempts to pull the OID representing emailAddress (OID = 1.2.840.113549.1.9.1) first, and use that as the username of the person logging in for the authorization layer. If this property is empty, it then tries to use the commonName attribute (OID = 2.5.4.3).

For example: CN=lvintern,CN=Users,DC=example,DC=spotfire,DC=com.

If you have a custom or non-standard OID in each certificate, you can specify the number. This is a list of comma-separated values. Note that using these properties is lightly discouraged in production environments because of potential security implications (for example, if your certificate is visible and its numbers match the numbers that appear in the OID configuration). If possible, use only one OID in this property to minimize exposure.

Be careful, as fallbacks can expose potential security vulnerabilities; make sure your certificate authority or keystore does not approve malicious certificates that contain multiple valid usernames in each fallback:

  userNameObjectIdentifierSearchPath = [
    "emailAddress",
    "userID",
    "CN",
    "DN"
  ]

If you want to use your server certificate as your internal user certificate, configure these properties in the configuration file of type ldmengine to rewrite your domain name into your internal user. This configuration is not intended for the LVInternal user but possibly for testing TLS web client authentication via extended key usage.

"liveview.security.auth.X509.internal.principal"="localhost"

The above property is the CN or email that would normally be pulled out of the server certificate (normally the domain name). Also, the domain name set in the property above should be set for the internal user you define in the property below.

Configure the following for the internal user:

"liveview.security.auth.X509.internal.user"="lvintern"

This property applies to the username (which usually is always going to be lvintern) you want to substitute for the principal above. For example:

name= "engine for security"
version= "1.0.0"
type= "com.tibco.ep.ldm.configuration.ldmengine"

configuration = {
  LDMEngine = {
    systemProperties = {
      "liveview.ssl.hostname" = "localhost" 
      "liveview.security.auth.X509.internal.principal"="localhost"
      "liveview.security.auth.X509.internal.user"="lvintern"
     }
      jvmArgs = [
      "-Xmx1024m"
      "-Xms512m"
      "-XX:MaxPermSize=768m"
    ]
  }
}