How does SSL fit into a deployment of Identity Manager?
IBM Security Identity Manager is an enterprise infrastructure application that relies on many distributed processes to perform its tasks. These processes communicate with each other over a TCP/IP network which may or may not be considered secure. It is recommended, but not required, that these connections be secured by SSL (or TLS in the case of FIPS). IBM does not provide these SSL certificates, so it is incumbent on the customer to acquire these certificates and have a general understanding of how SSL works. With the necessary certificates, there are many ways to configure ISIM to use them.
One of the many choices regarding SSL is whether to use 1-way or 2-way SSL. 1-way SSL involves a client, usually the ISIM server, connecting to a remote process, usually an adapter. The remote process presents a certificate, and the client attempts to locate in its truststore the Certificate Authority (CA) that signed it. If a match is found, the two sides then negotiate a cipher to use, and commence encrypted communication. With 2-way SSL, the process is nearly identical. The only difference is that after the client confirms the certificate from the remote process, the client must now provide a certificate that the remote process can verify with a CA from its truststore. There is no difference in the encryption level between 1-way and 2-way, the only benefit is that it makes it harder for an attacker to spoof one side of the conversation since they must be able to present a certificate signed by a CA known to the other side. This benefit is offset by the facts that it's more complicated to setup, with more moving parts it's more likely to have communication failures, and there are more certificates that will expire and eventually need to be replaced. In general, unless there are specific requirements for 2-way SSL, 1-way SSL is the best option for a simpler encryption solution.
Another common point of confusion about SSL involves keystores and truststores. In reality, there is no difference between the two, as they're just containers for holding certificates. There is no reason the same file could not be used for both the keystore and truststore settings. However, they are usually different files just to make it easier for the administrator to understand them. A keystore is used to hold the certificates presented to a calling process. A truststore is used to hold the CA certificates that signed the certificates being presented.
ISIM is an application that runs inside WebSphere, which can lead to some confusion because WebSphere handles SSL very differently from ISIM. The WebSphere SSL repertoires contain the certificates used for the various WebSphere processes to communicate among themselves using SSL. They can also be used as the keystores and truststores for ISIM if configured correctly. It is recommended that the WebSphere files be left alone and new keystores and truststores be created for use by ISIM. But if you plan to reuse the existing WebSphere ones, you MUST make sure the WebSphere certificates are still present - either copy your certificates into the WebSphere file, or copy the WebSphere certificates into your new file, but do NOT simply point the WebSphere default key/truststores to a newly created file with just your certificates or WebSphere will be unable to communicate with itself.
There are a few ways to configure ITIM to find the truststore with the CA certificates it needs. The first involves simply adding them to the "cacerts" file in $WEBSPHERE_HOME/AppServer/java/jre/lib/security. The default password is "changeit", and this file is used by the JVM in the absence of any additional configuration. Another method is to define JVM parameters that specify the path and password to the keystore and truststore files to use. Details can be found in the "Overriding cacerts truststore" link below. One drawback to this approach is that the password may be visible in the "ps" output on a UNIX system. To prevent this, you can place the details in a file, and pass that file name to the JVM. Please see the "Masking password for alternate truststore" link below for more details. The above methods will work for all ISIM communication, whether it be to an ADK adapter, ITDI, LDAP, or anything else. If you only want to setup SSL to ADK adapters, or want to separate that out for some reason, then another method involves setting DAMLContext properties in $ITIM_HOME/data/enRole.properties. Please see the "Alternate adapter truststore" link for more details.
When setting up SSL with one of the ADK adapters (ie. one that doesn't require Tivoli Directory Integrator), there are two types of certificates that can be used. The first method involves using certTool to generate a Certificate Signing Request (PKCS10). This will store the private key in the adapter registry, and generate a public key (certificate) that is ready to be signed. This certificate must then be given to a 3rd party signing authority (e.g. Verisign), or to an in-house signing authority (e.g. Microsoft CA certificate server), at which point it will become a signed certificate (PKCS7). The signed certificate must then be loaded into the adapter with certTool, and the CA certificate that signed it must be loaded into the truststore on the ISIM server. The second method involves using ikeyman under WebSphere to create a self-signed certificate. This must be exported as a PKCS12 file, which will contain both the signed public key and the corresponding private key. This file can then be loaded into the adapter registry using certTool. More detailed information can be found in the Installation Guide provided with the adapter you are configuring. Also, it is important to note that certTool can only generate requests for a 1024-bit certificate. It can import 2048-bit certificates, it just can't create them. If you need a certificate larger than 1024-bit, please see the link below for using 2048-bit certificates.
enrole itim tim isim