The configuration parameters of a TDI component in a Config can be "string", "number", "boolean", and so on. One of the available types is "password". If a configuration parameter is of type password, then the Configuration Editor shows its value in the component configuration window as a sequence of ‘*' characters - both when typing in a new password, and when opening an existing configuration for editing or running.
TDI saves configuration information in an XML file which contains clear text for all configuration values. This includes sensitive information like passwords. TDI supports encryption of the entire configuration file but does not encrypt or protect sensitive information when the configuration file is saved in clear text.
TDI provides a way to better protect passwords that are needed for its various components; it hides the passwords in a clear text configuration and provides default security for passwords that are stored. In order to do this component passwords are defined (stored and retrieved) in a default property store, instead of in the configuration file. In TDI 7.1, a user defined property store can be any system for which there is a connector and the default property store most likely be an external properties file. All component passwords will by default go to this default property store, instead of in the configuration file (as it is in older versions of the product). Thus, passwords can be isolated from the configuration file unless explicitly overridden by the user (may be appropriate for initial development).
The password protection mechanism is directly related to the configuration windows offered to the user. The configuration windows, or forms, contain descriptions of each parameter and its syntax. One type of syntax is password which causes the Configuration Editor to use a password text field for editing. Whenever the value for a password syntax component parameter is changed, the value of the password is saved in an external repository, called the Password Store. This external repository for passwords is configured in the Properties page in the configuration editor (Password-Store) and is specified in the configuration file for the current TDI solution. If no such property store is configured the password is saved in clear text in the configuration file.
If a default password store is configured, a unique property name is generated the first time a protected/password parameter is saved. This key is used as the key in the password store. The same property name is written to the configuration file as a standard property reference. When the value is later retrieved, standard property resolution takes place to retrieve the actual value from the password store.
If a Password Store is specified, a unique key is generated for the password and the password is saved encrypted in the Password Store under that key. In the configuration file, the password is referenced only by that key.
If no Password Store is specified, the password appears in plain text in the configuration file.
For example:
After the above procedure, in the configuration file of the created solution will contain lines that resemble the following text:
<parameter name="ftpPass">@SUBSTITUTE{property.MyProps:ftpPass-38ae53e8779cfd65}</parameter>
.........
<PasswordStore>MyProps</PasswordStore>
...and in the "MyProperties.properties" file there is a line like the following text:
{protect}-ftpPass-38ae53e8779cfd65={encr}GVJC0lA7VUiW=
This means that the FTP password configuration in the solution file references an encrypted property from the current Password Store - "MyProps". The property key used is "ftpPass-38ae53e8779cfd65".
TDI solution builders need a way to protect sensitive data, such as passwords, from being printed in clear text when tracing on the solution is needed. Therefore in TDI 7.1 some of the methods dealing with the Attribute class have been enhanced to say whether an attribute is protected or not. If the attribute is marked as protected and tracing is on, a fixed number of stars ‘*' is output instead of the actual value.
When connection parameters are found in the TaskCallBlock (TCB), the values never be logged directly by TDI. The fact that parameters were given is logged, but not the values themselves. If the solution needs to be debugged, those values can be dumped manually, for example using scripting.
Server Hook scripts are defined and made available by creating files in the "serverhooks" subdirectory of the solution directory. Scripts that contain sensitive information should be encrypted with the Server API before adding it to the directory. Scripts can be encrypted by using cryptoutils (see The TDI Encryption utility). Note that the TDI server only decrypts script files that have the ".jse" filename extension. The ".jse" extension indicates to the TDI server that the script file is encrypted. That is why, after you encrypt a Server Hook script file, make sure to change its filename extension to ".jse".
The Configuration Editor used to edit remote Config Files (that is, Config files on a remote system) is called the Remote Configuration Editor (Remote CE). The TDI 7.1 Remote CE is capable of starting AssemblyLines in configurations opened for editing. The Remote Configuration Editor is a client of the Server API of the remote TDI Server. Consequently the Remote Configuration Editor is authenticated and authorized as a client of the Server API. In order for this to work when SSL is used:
This SSL client authentication is needed because the Remote Configuration Editor uses listener objects so that it can be notified when an AssemblyLine has terminated and for this to work with SSL both the client must trust the server identity and server must trust the client identity.
Using a Remote Configuration Editor is a little different from using a local CE. When running a remote Configuration Editor to manage a Config on a remote system, be mindful of restrictions that apply to the CE in remote mode. Notable restrictions include:
For example: ldap://localhost:389 results in the Configuration Editor (CE) attempting to connect to the local LDAP server, rather than to the LDAP server on the remote computer.