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. In continued efforts to improve MID Server security, the
encryption algorithm has been enhanced. 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:
- The instance retrieves the encrypted password and the unencrypted
username from the instance database table.
- The instance decrypts the encrypted password, and then re-encrypts it
using the MID Server encryption key.
- 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.
- 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.
Note: In the Orlando release, the MID Server requires a minimum JRE version 1.8.0_161, and
recommended version 1.8.0_181. If you are using a lower version than 1.8.0_161, you may see
encryption related issues.
Security options
The MID Server provides built-in security options for other content in the configuration file,
such as the default encryptor, Windows Data Protection API, and options for custom
encryption.
