Customized security uses security files (with encrypted passwords), a new secret phrase, and passwords for the SDK usernames in the security files that are different than their default values. Under customized security, connection protocols are set to use the site secret and cleartext. This setup protects against eavesdropping and active attacks as well as casual inspection.

To configure customized security:

  1. Create a new secret phrase by using sm_rebond, as described in “Changing the secret” on page 100.

  2. Change the username and passwords in serverConnect.conf, clientConnect.conf, and brokerConnect.conf.

    These should provide access control by individual users. Consider using system authentication to authenticate Global Console users, as described in “System authentication” on page 93. The new usernames and passwords should also address connections between servers and servers or servers and clients.

    If your SDK software resides on a single host, a single username and password for automatic client authentication is usually sufficient. However, if you have clients, such as adapters, on multiple hosts, or generally in different security domains, you may use different usernames and passwords for manageability. For example, if there is reason to believe that the username and password from one machine have been compromised, you can change them without having to change the configuration on any other machine.

    To achieve such a configuration, you need to assign unique usernames and passwords to clients that you consider to reside in separate security domains. Add a line to grant access to each such username/password credential to the serverConnect.conf file of each server the client will access. Add a corresponding line to the clientConnect.conf file that the client will use.

    Note:

    If you have multiple security domains on a single host, use the SM_CLIENTCONNECT environment variable so that different clients read different clientConnect.conf files. You can use the --env option of the sm_service utility to set the environment value when the service starts.

  3. Configure the different SDK components to communicate with encrypted connections. The types of allowed connections depend on the versions of SDK software in use.

    • Most connections should be encrypted. The Broker does not need to support cleartext if all clients can make encrypted connections.

      Encrypted connections on page 105 provides additional information.

  4. At the highest security level, you should run with a secure Broker as well. Setting up a secure Broker is described in “Configuring a secure Broker” on page 108.