Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

MID Server security and encryption

Log in to subscribe to topics and get notified when content changes.

MID Server security and encryption

After configuring your MID Server, you can add security by encrypting MID Server parameter values in the config.xml file. Encryption protects data that the MID Server returns to the ECC Queue. Other available security options include the authorization of SOAP requests, restricting access to the MID Server configuration file, and establishing secure socket layer (SSL) connections.

How MID Server password encryption works

The username and password are initially set in the config.xml file on the MID server. When the MID server retrieves the credentials, it replaces the clear-text password with an encrypted password automatically, using an AES128 encryption algorithm. The MID server also maintains an encryption key that is generated each time it starts and remains in memory and not on the hard disk. When credentials need to be sent from the instance to the MID server, the following process takes place:
  1. The instance retrieves the encrypted password and the unencrypted username from the instance database table.
  2. The instance decrypts the encrypted password, and then re-encrypts it using the MID server encryption key.
  3. The username and re-encrypted password are sent to the MID Server through the encrypted TLS session was already established between the MID server and the instance.
  4. The MID server receives the credentials and decrypts the password in memory before using the credentials for remote operations. At no point is the credential password stored on the disk in an unencrypted format.

MID Server encryption keypairs

Automation credentials are secured by encrypting them in the instance with the MID Server’s trusted public key prior to transmission. When the MID Server is created, it generates a keypair, consisting of a public and private key. After the MID Server is validated, it can use the private key to decrypt automation credentials. You should occasionally rekey the MID Server to meet your organizations security requirements. See Rekey a MID Server for instructions.

SSL certificates

You can add certificates to the MID Server if you want communication to occur over SSL. You can add these certificates to the cacerts keystore file:
  • Signing Certificate Authority (CA) certificate
  • MID Server certificate

See Add SSL certificates for the MID Server for instructions.

Note: The MID Server does not support SSL when importing data from an integration, such as an LDAP server.

Basic authentication credentials and SOAP requests

You can enforce basic authentication on each request. The MID Server is not able to communicate through a proxy server if the proxy server supports only NTLM authentication. You can use basic authentication with a proxy server or create an exception for the MID server host.

Supplying basic authentication information, regardless of whether it is required, has an added advantage. The web service invocation creates or updates data using the supplied credentials. For example, when you create an incident record, the journal fields have the user id of the basic authenticated user instead of the default Guest user. This behavior allows you to identify data added by a specific MID Server.

You can set basic authentication credentials for SOAP requests. See Require basic authorization for incoming SOAP requests for instructions. Each SOAP request contains an Authorization header as specified in the Basic Authentication protocol.

Note: The setting for enforcing strict security controls how the instance uses the credentials you provide for the MID Server. When the setting is enabled, you must provide a user ID with access to the tables the MID Server is trying to access. When the setting is disabled, any valid user ID allows the MID Server to access to all tables.