Miscellaneous Config File features

The "password" configuration parameter type

The configuration parameters of a Tivoli® Directory Integrator 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.

Component Password Protection

Tivoli Directory Integrator saves configuration information in an XML file which contains clear text for all configuration values. This includes sensitive information like passwords. Tivoli Directory Integrator supports encryption of the entire configuration file but does not encrypt or protect sensitive information when the configuration file is saved in clear text.

Tivoli Directory Integrator 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 Tivoli Directory Integrator 7.1.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).

Saving passwords to configured Properties

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:

1. Create a new project from the Configuration Editor
2. Right-click on the "Properties" folder in the navigation view and select "New Property Store" called "MyProps".
3. From the "Connector" tab of the newly created Property Store, type in "MyProps.properties" in the "Collection Path/URL" field.
4. Specify that the new Property Store is used as the Password Property Store (right-click on the new properties store in the navigation view and select Password Property Store).
5. Add a new assembly line with a FTP Client Connector.
6. Enter a password in the "Login Password" field of the FTP Client Connector.
7. Save the solution and close the Configuration Editor.

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".

Protecting attributes from being printed in clear text during tracing

Tivoli Directory Integrator 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 Tivoli Directory Integrator 7.1.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 Tivoli Directory Integrator. 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.

Encryption of TDI Server Hooks

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".

Remote Configuration Editor and SSL

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 Tivoli Directory Integrator 7.1.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:

1. The server to which the Remote Configuration Editor connects must be configured to require SSL client authentication. This is a configuration of the Server API - for details see SSL-based authentication.
2. The Remote Configuration Editor TDI instance must be configured to supply SSL client authentication. This is configured in a SSL client authentication.

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 the Remote Configuration Editor

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, you must be mindful of restrictions that apply to the CE in remote mode. Notable restrictions include:

• When editing Config files locally, it is sufficient to have appropriate file system access (read and write) to the Config file. However, when editing a remote Config, you must have Admin privileges on the remote Config Instance.
• When connecting to a data source (using Connect buttons in mapping windows), these connections are evaluated locally.

  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.

• When generating WebServices-related connectors results in function components that generate the WSDL file, .jar files (using Complex Type Generator), and so on, you are generating them locally. These components are not generated on the remote system to which the CE is connected and must be uploaded manually to the remote system for deployment.
• The remote CE only allows editing and viewing of those Configs that are present in the folder specified by the api.config.folder property.
• When working with System Store operations (such as deleting the Iterator state key, and so on) that are available in the CE, work with the local system store and not with the remote Tivoli Directory Integrator computer's System Store. Only when the AssemblyLine (AL) is executed does the AL connect to the remote System Store, because at AL execution time, the AL is running inside the remote JVM.
• When you use the Parameter Substitution editor (available with Ctrl-E), the editor shows only the local properties, and not the properties set on the remote system. Similarly, creating and saving a new property store (file type) stores the property store (file) locally.
• When using the Configuration Editor to edit remote Config files, you are subject to Server API authentication and authorization, because the CE is acting as a client application. Therefore, in order to use the CE in this way, you must have admin access on the Remote Server.
• When using the Remote Server, the Remote Server itself must have sufficient access to the local file system where the Config files are stored. If the ConfigfFiles are stored on a read-only file system or a file storage location where the user ID under which the Remote Server is running does not have write access, you cannot edit remote Configs.