There are several layers in the IBM TDI Password Synchronizer architecture.
TDI Password Synchronizer architecture
Target System on the diagram designates the software system where we want to intercept password changes. The Password Synchronizer component hooks into the Target System using custom interfaces provided by the Target System. The Password Synchronizer component intercepts password changes as they occur in the Target System and before the password is hashed irreversibly.
The Java proxy component is a proxy in the sense that it receives passwords from the server plug-in and redirects them to the Password Storage component. The proxy acts as a container for the Password Storage component - it manages the life-cycle of the Password Storage component and handles inter-process communication with the TDI plug-ins.
The Java Proxy logs any raised errors in the configured log file. If any initialization error is raised the Java Proxy will fail to load. If a runtime error occurs the error is logged for later investigation but the execution of the server continues. This provides high availability in case of a temporary environment change/failure.
Also, a Password Store component is deployed on the Target System. Once the Password Synchronizer intercepts a password change it immediately sends the password to the Password Store, using the aforementioned Java proxy process. The Password Store encrypts the password and sends it to a Password Storage.
The Password Storage is the second layer in the architecture and represents a persistent storage system (for example, an LDAP directory, or WebSphere MQ Everyplace) where the intercepted and already-encrypted passwords are stored in a form and location that are accessible from the IBM TDI . The Password Storage can reside on the Target System machine or on another network machine.
The third layer of the architecture is represented by the IBM TDI . The IBM TDI uses a Connector component to connect to the Password Storage and retrieve the passwords stored there. Once in the IBM TDI , the passwords are decrypted and made available to the AssemblyLine that synchronizes them with other systems. The IBM TDI can be deployed on a machine different than the Target System and Password Storage machines.
The next layer in the architecture (in the data flow direction) is represented by the systems whose passwords are synchronized with the Target System. The password synchronization AssemblyLine is responsible for connecting to these systems and updating the passwords there.
The Java proxy component is a proxy in the sense that it receives passwords from the server plug-in and redirects them to the Password Storage component. The proxy acts as a container for the Password Storage component - it manages the life-cycle of the Password Storage component and handles inter-process communication with the TDI plug-ins.
The proxy and the directory plug-in share a common binary command protocol. The communication happens over sockets. The proxy acts as a server, listening for commands. The directory plug-in connects to the proxy, transmits a command and reads the response.
Depending on the configuration the Java Proxy can also do a preliminary validation on the passwords strength. Currently this validation can only be done against the password policies defined in a remote ITIM server. The Java Proxy is responsible for storing password changes received by the plug-in in the configured password store.
The communication between the various plugins and the Java Proxy is done over sockets. It is restricted to the loopback network interface only. Apart from that a two way authentication takes place each time a connection between the client plugin and the Java Proxy is established. The authentication is based on File System permissions. The authentication procedure uses the Authentication Folder (the place where the pwsync.props file is situated). It is important to protect the Authentication Folder by means of file system permissions because the authentication process creates one-time-passwords and stores them as files in that folder.
The Authentication Folder need to be secured after the Password Synchronizer is properly setup. In order to do that the folder must be made readable/writable by only the user that executes the process loading the plugin. For example for the Domino HTTP Password Synchronizer the user "notes" is usually the one used to run the Domino Server with. That user must have full control over the Authentication Folder in order for the Password Synchronizer to work.
The Java Proxy needs read/write privileges to the Authentication Folder too. That process is automatically started from the plugin side and thus is executed with the same privileges as the plugin. If for some reason the Java Proxy is started manually by another user then that user need to be granted the read/write access to the Authentication Folder as well. For example if the user user has full control over the Authentication Folder we will have to execute the commands with that user’s privileges in order for the authentication to succeed.
runas /user:user startProxy.bat configuration_file
runas /user:user stopProxy.bat configuration_file
su - user
startProxy.sh configuration_file
stopProxy.sh configuration_file
The steps outlined in this section will restrict the access to the Authentication Folder for the Windows Password Synchronizer. The plugin is executed in the LSA process owned usually by the local system account. Since that account is part of the Administrators group we need to grant access only to that group by doing the following:
If you are setting up a different Password Synchronizer make sure the appropriate user/group is granted the required privileges.
The steps outlined in this section will restrict the access to the Authentication Folder for the PAM Password Synchronizer. For this purpose auth_dir will refer to the folder where the authentication process is taking place.
chown -R root:root auth_dir
chmod -R 700 auth_dir
The Password Store is the place the Java Proxy will store the received passwords.
The Password Store used by a Password Synchronizer can be easily changed when necessary. For example, a Password Synchronizer for IBM Tivoli Directory Server is deployed and configured to use the LDAP Password Store. At some time we decide that we need to use the JMS Password Store. Then we need to configure the JMS Password Store, change a single property of the Password Synchronizer, and restart the IBM Tivoli Directory Server. New password changes are then stored in your designated JMS Password Store, it is not necessary to install the solution again.
For simplicity, the previous diagram shows password interception on a single Target System. Actually, a password synchronization solution might need to intercept password changes on several Target Systems. This is where the layered password synchronization architecture brings additional value in terms of scalability and customization options:
In either (or both) of these previous approaches, it is possible to add, remove or change Target Systems in an already existing solution by focusing mainly on the new functionality without affecting the rest of the solution.
On the other end of the data flow, where passwords are updated in systems that we want to keep synchronized, the password synchronization architecture benefits from the inherent scalability of the IBM TDI . Updating passwords on yet another system might be as easy as adding a new Connector in the password synchronization AssemblyLine.
In the case where the Target System is also one of the systems updated with the intercepted passwords from other systems, special care must be taken to avoid circular updates. The implementation on the IBM TDI side must build logic that does not update a system with passwords intercepted on that same system.
Public-private key infrastructure is used to provide secure transport and intermediate storage of password data.
The Password Store components use a public key to encrypt password data before sending it on the wire and storing it in the Password Storage. The IBM TDI AssemblyLine or specialized Connectors have the corresponding private key and use it to decrypt password data retrieved from the Password Storage.
An additional layer of security is added by Password Store components supporting SSL.
The installation folder of each password synchronizer and all files in it must be protected against non-trusted users on the host operating system. The preferred way to achieve this is by setting proper file system permissions - non-trusted users and groups must not have any access (read, write, execute) to the installation folder or the files of the password synchronizer.
Functionality for preventing and dealing with possible password de-synchronization is built into the password synchronization workflow.
The Password Synchronizer and Password Store components together provide functionality to deal with cases where an external storage system is not available or malfunctions.
The Password Store always reports to the Password Synchronizer whether or not the password was successfully stored into the Password Storage. The Password Synchronizer component can do the following to prevent or handle possible password de-synchronizations: