Configure Runtime Security

Overview

A Runtime, installed with the default configuration, listens to localhost only and requires to log in with a user-defined in the configuration file to perform operations such as listing or starting sessions.

You can enhance and customize the security of the Runtime using the engineParameters.xml configuration file:

Secure Communications with TLS, for RMI, HTTP, and REST/SOAP.
Configure Authenticated Access with roles and permissions.
Restrict Access by Hostname/IP Address

A basic secured configuration sample is given below.

<parameters>
<...>
  <engineParameters>
  <...>
   <parameter name="rmiEnableTls" value="true"/>(1)
   <...>
   <parameter name="webServiceSecureProtocol" value="TLSv1.1"/>
   <parameter name="webServiceKeyStoreFile" value="D:/keystore/mykeystore.jks"/>
   <parameter name="webServiceKeyStoreType" value="JKS"/>
   <parameter name="webServiceKeyStorePassword" value="keystore_password"/>
   <parameter name="webServiceKeyAlias" value="key_alias"/>
   <parameter name="webServiceKeyPassword" value="key_password"/>
   <...>
  </engineParameters>
  <...>
  <security> (2)
   <user name="admin"  uncryptedPassword="admin-password" roles="Admin"/> (3)
   <user name="developer"  uncryptedPassword="developer-password" roles="Connect View Execute"/> (3)
   <user name="viewer"  uncryptedPassword="viewer-password" roles="Connect View"/> (3)
   <allow address="192.168.0.42"/> (4)
   <allow address="192.168.0.43"/> (4)
  </security>
<...>
</parameters>

1	Secure RMI, HTTP, and SOAP endpoints with TLS.
2	Secure access with users, roles, and network restrictions. The security configuration is mandatory.
3	User definition, with associated roles. It is mandatory to define at least one user.
4	Optional network access restriction by IP or hostname address.

Secure Communications with TLS

Configure the Runtime

To enable TLS for RMI, HTTP, and Web services endpoints, you have to define the following parameters:

<parameters>
<...>
  <engineParameters>
   <...>
   <parameter name="rmiEnableTls" value="true"/>
   <...>
   <parameter name="webServiceSecureProtocol" value="TLSv1.1"/>
   <parameter name="webServiceKeyStoreFile" value="D:/keystore/mykeystore.jks"/>
   <parameter name="webServiceKeyStoreType" value="JKS"/>
   <parameter name="webServiceKeyStorePassword" value="keystore_password"/>
   <parameter name="webServiceKeyAlias" value="key_alias"/>
   <parameter name="webServiceKeyPassword" value="key_password"/>
   <...>
  </engineParameters>
<...>
</parameters>

The keystore and certificate details are mandatory if you enable TLS. They are used to secure all the protocols: RMI, HTTP, and Web Services endpoints.

Table 1. Communication Security Parameters
Parameter	Description
`rmiEnableTls`	Set to true to secure the RMI protocol with TLS.
`webServiceSecureProtocol`	Protocol to be used to secure the endpoints. For example, TLSv1.1.
`webServiceKeyStoreFile`	Path to the Java keystore containing the certificate used to secure the endpoints.
`webServiceKeyStoreType`	Java keystore type, such as `JKS`.
`webServiceKeyStorePassword`	Password of the keystore file.
`webServiceKeyAlias`	Alias of the key in the keystore.
`webServiceKeyPassword`	Password of the key.

Configure the Clients

When the Runtime endpoints are secured with TLS and a certificate, clients such as Designer, Analytics, or command line scripts use that certificate to communicate with the Runtime:

If you use a certificate signed by an authority, you do not need to provide it to the clients.
If you use a self-signed certificate, you must provide it to the clients.

Configure Authenticated Access

Summary

You must define users and their associated roles that will be used to connect to the Runtime.

At least one user must be defined in the Runtime configuration file. The Runtime will not start if there is no security element or no user defined in the configuration.

Standard Users

Users are defined as shown below:

Example 1. User Configuration

<parameters>
<...>
  <security>
   <...>
   <user name="user01"  password="xxxxxx" uncryptedPassword="password" roles="Connect View Execute"/>
   <user name="user02"  password="xxxxxx" uncryptedPassword="password" roles="Connect View Execute"/>
   <...>
  </security>
<...>
</parameters>

Table 2. User Configuration Properties
Parameter	Description
`name`	User name, that will be used as the login credential.
`password`	Encrypted password of the user.
`uncryptedPassword`	Unencrypted (plain text) password of the user.
`roles`	Space-separated list of roles for the user. The possible roles are: `Connect`: The user can connect to the Runtime (required) `View`: The user can list and view all the sessions of the Runtime `Execute`: The user can execute deliveries on the Runtime `Admin`: The user has the full permissions on the Runtime. This is required for operations such as purging the sessions or scheduling deliveries.

Passwords are encrypted using the encrypt <password> command on the Runtime engine console (engine command line tool).
Only one of the password or uncryptedPassword properties should be set.
Multiple roles can be assigned to one user, separated by space characters

Anonymous User

You can define an anonymous user to give access to the Runtime without authentication, with default roles. This is optional, and only one anonymous user can be defined.

When the anonymous user is defined, the Runtime can be accessed with no authentication, and the tasks associated with the defined roles can be performed.

Example 2. Anonymous User Configuration

<parameters>
<...>
  <security>
   <...>
   <user anonymous="true" roles="Connect View"/>
   <...>
  </security>
<...>
</parameters>

Table 3. Anonymous User Configuration Properties
Parameter	Description
`anonymous`	Defines that this user is the anonymous user. Must be set to `true`.
`roles`	Space-separated list of roles for the user. The possible roles are: `Connect`: The user can connect to the Runtime (required) `View`: The user can list and view all the sessions of the Runtime `Execute`: The user can execute deliveries on the Runtime `Admin`: The user has the full permissions on the Runtime. This is required for operations such as purging the sessions or scheduling deliveries.

You can define both an anonymous user with limited privileges and authenticated users with more privileges.

Restrict Access by Hostname/IP Address

You can define the machines allowed to connect to the runtime by their hostname and IP address.

The default configuration file allows connecting from the local machine only. You can define additional allow nodes to authorize multiple machines.

Access restriction is optional and can be disabled by removing all the allow nodes.

Example 3. Hostname/IP Address Configuration

<parameters>
  <...>
  <security>
   <...>
   <allow address="localhost"/>
   <allow address="192.168.0.42"/>
   <allow address="Hostname or IP Address"/>
   <...>
  </security>
  <...>
</parameters>