The Administration and Monitoring Console (AMC) is a web-based application for monitoring and managing remote TDI solutions. The following features of AMC have been improved:
AMC uses the Remote Server API to communicate with TDI. For this reason, all the security restrictions and configuration settings that are applicable to TDI Remote Server API clients (as mentioned in previous sections) are valid for AMC too.
Action Manager is installed with AMC. Action Manager configures itself and behaves based on rules set in the AMC database by AMC users. To monitor remote AssemblyLines and to take action based on configured rules, Action Manager, just like AMC, uses the TDI Remote Server API to communicate with TDI servers.
Communication between AMC and AM using RMI is not protected in any way.
Multiple TDI servers can be registered with AMC. Each TDI server may be configured differently; one TDI server could be running with SSL off, one with SSL on, one with Custom Authentication on and SSL on - and various other combinations. AMC can be used to connect and administer any of these servers simultaneously. As mentioned earlier, to configure TDI to run in SSL mode the api.remote.ssl.on property should be set to true in global.properties (or solution.properties).
As AMC is a web application running inside a Web Container it automatically inherits some properties and security restrictions from the Web Container. For instance, if the Web Container has an SSL keystore or SSL truststore configured, then that would be automatically applicable to AMC. But AMC can also override that - and specify its own keystore and truststore.
For being able to communicate with TDI Remote Server API running on SSL, AMC must have a keystore configured which contains the certificate that is trusted by the TDI remote Server API (that is, it must be present in TDI's truststore's trusted certificates section) and AMC must have a truststore configured which contains the certificate that is sent by the TDI remote Server API. In other words - the certificate that is present in TDI server's keystore must be present in AMC's truststore and the certificate that is present in TDI truststore must be present in AMC's keystore.
For example, the default installation of TDI is shipped with certain stores (.jks files). When we run TDI in SSL mode, then to connect to AMC its keystore and truststore must both be set to the same value: TDI_install_dir/serverapi/testadmin.jks and the password being "administrator". Since testadmin.jks contains both trusted certificates and signer certificates, a connection gets established. It is recommended that you set up our own SSL keystores and truststores.
In AMC, the path of the truststore and keystore can be set by logging into AMC as "TDI AMC Admin" (Console Administrator) and navigating to the following window: Advanced -> Console Properties -> SSL settings. The settings for truststore and keystore are written to amc.properties file inside the tdiamc folder in Web Container. We can alternatively choose to edit the amc.properties file directly. With TDI 7.0, AMC can be deployed in ISC Standard Edition (SE) or in ISC Advanced Edition (AE). Depending on the ISC runtime, the location of the testadmin.jks file varies. For example, if AMC is deployed in ISC SE, then the location will be ISC_RUNTIME_INSTALL_DIR/runtime/isc/eclipse/plug-ins/AMC_7.0.0. On the other hand, if AMC is deployed in Tivoli Integrated Portal (ISC embedded), then the location is ISC_RUNTIME_INSTALL_DIR/systemApps/isclite.ear/tdiamc.war. The keystore and truststore password are set to "administrator" by default. To establish an SSL based connection with a remote TDI server, start the server in "SSL enabled" mode, and for a Non SSL based connection, start the server in "SSL disabled" mode.
Attention: Default SSL settings are provided. However, using the default certificates does not increase the security more than just using a plain connection, so after installation, we should replace the default SSL certificates and update the keystores and truststores accordingly in order to increase security.
For each TDI server running over SSL that you wish to register with AMC, import the necessary certificate into AMC's truststore and the necessary AMC's key certificate into TDI's truststore. The idea here is that AMC must trust TDI and TDI must trust AMC to be able to make a secured two-way SSL connection.
Since AMC runs inside a Web Container, the URL for AMC is http://hostname:port/ibm/console.
Action Manager monitors running Configs and AssemblyLines on remote TDI Servers based on rules configured in AMC. Action Manager ships with the keystore and truststore required to connect to a remote TDI server. The SSL properties are defined in the am_config.properties. See details on how to configure AMC for SSL in previous sections - the same is applicable for Action Manager.
AMC can connect to multiple TDI Servers remotely. Each Server can be configured in one of the following ways:
This section looks at each of these cases in detail.
When a remote TDI server is configured for non SSL (that is, api.remote.ssl.on=false) then the keystore or truststores of AMC do not come into play, even if correctly configured - since no SSL connection is being attempted. In this case the AMC Server's computer IP address must be registered with the TDI server. This is done by editing the global.properties (or solution.properties) file. The property to update is: api.remote.nonssl.hosts. Once the AMC computer's IP address is entered in the global.properties file of the remote TDI server, AMC is able to connect to that particular server. It is a way of saying - I trust remote server connections (AMC connections) from only those computers whose IP addresses I have mentioned in my api.remote.nonssl.hosts property.
If the TDI server is running on the same computer as AMC, then editing this property is not required.
When a remote TDI server is configured for SSL (that is, api.remote.ssl.on=true), then the SSL keystore and truststore for AMC must be setup appropriately.
For details on this, see the previous section on AMC and SSL. In addition to being configured for SSL or Non-SSL, a remote TDI server may also require Custom Authentication - in which a username and password must be passed while making a connection to the remote TDI server. The remote TDI server validates this user name and password against some third party repository like LDAP, file, database, script, and so on and then make a decision on whether to allow the Server API client to make a connection or not. In such cases, while registering a server with AMC (Servers -> Modify Server) in the Authentication mode window - select LDAP or Custom Authentication and enter the Username and Password that AMC must pass every time it attempts to connect to the specified remote TDI Server.
If the Username or Password (in case of custom authentication) or SSL keystores or truststores (in case of SSL) are not set up correctly, then AMC is unable to connect to the remote TDI Server and show that server as "Stopped" or "Not running."
Every user (or group) in AMC can be assigned one of the following roles in AMC for a particular Solution View. This role assignment can be done in the Solution Views window by selecting a particular Solution View and by clicking Configure Access Control Lists (ACLs). The Configure ACLs window displays. Select the Name of the user we want to configure and click Configure Users on the toolbar. The Configure Users window displays. Select the User ID and select one of the available roles:
You must reload Solution Views created using the Auto Update option. Use the Refresh Solution View in the Solution Views window. For Solution Views marked for auto update, reload the config file and refresh the Solution View by clicking the Refresh Solution View. If a user fails to refresh a Solution View created using the Simple option and flagged for auto update, the Solution View may cause inconsistencies in the AMC database. Inconsistencies in Solution Views that are not updated could result in incorrect behavior by the Action Manager.
These roles are in increasing order of privilege - indicating that Config Admin is the highest privilege and Read is the lowest. Any functionality that is available to a user with "Read" role for a Solution View, definitely is available to a user with "Execute" privilege on that Solution View. Any functionality that is available to a user with "Execute" privilege on a Solution View, is available to a user with "Admin" privilege, and so on.
The following is the meaning of these roles
The above roles can be assigned to any Group too. Therefore, if a user "test" and "tdi" are part of the "DBAdmin" group, and the "DBAdmin" group is given "ConfigAdmin" privilege over a Solution View "SynchDatabase", then both "test" and "tdi" automatically get ConfigAdmin privilege over the "SynchDatabase" Solution View.
Notes:
Any password field that is stored in the amc.properties file, such as LDAP Bind password, keystore password, and so on, are all encrypted before being written to the amc.properties file. Also, AMC never displays any Password fields or protected fields on console. All such fields are masked out.
AMC allows users to load and connect to password protected configs. On the Load Reload window of AMC, a password text box has been provided - where the users must enter the password of the config they are attempting to start before clicking Start. Similarly, in the Action Manager Screen - for the Start AssemblyLine action, a password field has been provided where the user can enter the password of the config. Action Manager passes this password while attempting to start the Config.
AMC cannot detect that the remote config being started is a password protected config. For this reason, if the password is not specified or incorrectly specified, then the user just see an error message saying - "Unable to start the config". The user can see the TDI Server logs where an exact message is provided.