Some TDI components give you the opportunity to use HTTP Basic Authentication as authentication mechanism. As the name says it is basic (simple) authentication. HTTP Basic Authentication should not be considered secure for any particularly rigorous definition of secure, because the credentials are base64 encoded and they can be easily decoded by someone. You should use more complex schemes to protect their data (for example a combination of turned on SSL and HTTP Basic Authentication). If the component supports HTTP Basic Authentication, then we see the following parameter:
The Domino APIs for SSL do not use JSSE, and are instead Domino-specific. This means that the TDI truststore and keystore (see section Client SSL configuration of TDI components) do not play any part in SSL configuration for the Domino Change Detection connector. For SSL configuration of the Domino Change Detection connector, a TrustedCerts.class file is used. This file is generated every time the DIIOP process starts (in the Domino Server) and must be in the classpath of TDI (that is, the ibmdisrv or ibmditk shell scripts which start the TDI server and TDI Configuration Editor respectively). You must copy the TrustedCerts.class to a local path included in the CLASSPATH or have the Lotus\Domino\Data\Domino\Java of the Domino installation in the classpath. Whether the TDI truststore or keystore are set or not in global.properties (or solution.properties) is of no consequence to this connector.
The above is related to the configuration of SSL for the Notes Connector and the Domino Change Detection Connector since they use SSL over IIOP.
The cn= portion of the distinguished name (dn) of a certificate to be used with the TDI Web services Server Connectors must match the DNS name or IP address of the host computer on which TDI is running. Otherwise an Exception is thrown, because the client not be able to establish an SSL connection to the TDI Web services Server Connector. An example of the cn= portion of the distinguished name of a certificate follows: cn=www.myserver.com. (This constraint about the distinguished name in the server's certificate comes from the HTTPS protocol - see rfc2818 "HTTP over TLS.")
If TDI needs to use both a client and a server certificate only the default certificate configured in global.properties or solution.properties is used, then this must be the same certificate. An alternative would be to write a custom implementation of the SSLSocket or the SSLServerSocket Java class and make it use a certificate different from the default.
The following command line creates a self-signed server certificate in the keystore named "MyServerKeyStore.jks".
keytool -alias MyServerCertAlias -keyalg RSA -genkey -dname cn=<server_ip_address> -validity 365 -keystore MyServerKeyStore.jks -storepass mystorepass -keypass mykeypass
The alias of the created certificate is "MyServerCertAlias". The RSA algorithm is used to create the key pair. The distinguished name of the certificate is the IP of the server. The certificate is valid for 365 days (one year). The password of the keystore is "mystorepass". The password of the created private key is "mykeypass". The created certificate can then be configured for use by setting the following properties in the global.properties or solution.properties file:
api.key.alias=MyServerCertAlias api.keystore=MyServerKeyStore.jks
TDI MQe components can be deployed to take advantage of MQe Mini-Certificate authenticated access. To use these MQe features, it is necessary to download and installation Websphere MQ Everyplace version 2.0.1.7 and WebSphere MQ Everyplace Server Support ES06. Use of certificate authenticated access prevents an anonymous MQe client Queue Manager or application submitting a change password request to the MQe Password Store Connector.
For more information on configuring MQe authentication with Mini-Certificates, see the "Authenticated MQe Access" section in Chapter 8 "MQ Everyplace Password Store" of the IBM TDI V7.1 Password Synchronization Plug-ins Guide.