Securely Connect Mule to IBM i/AS400

Anyone who has been on the receiving end of a PCI audit knows that encrypting data in transit is a sensible thing to do. It's a must-have requirement for sensitive customer data, personally identifiable information, and, as a general rule, should be applied by default unless there's a compelling reason not to. In this article, I will show how to securely connect Mule to IBM i (AS/400, iSeries, System i).

Mule flows typically communicate with IBM i data and business logic via the following transports:

• AS400 connector: Works with data queues and system commands
• Database connector: Facilitates direct access to application data and calls to DB2 stored procedures
• Other TCP based protocols: (HTTP, FTP, etc.)

In this article, I will show how to setup IBM i server encryption and secure Mule database and data queue communications.

IBM i is known for bullet-proof security capabilities. The remote clients interface with the system via host servers that manage the access to specific type of IBM i resources such as DB2 database, file systems, data queues, etc. The host servers can be configured to support or require SSL connections, both for the data encryption and client authentication. All host servers can use the same certificate or individual certificates.

In order to securely connect Mule to IBM i, the certificates must be configured and applied to appropriate host servers. In case of self-signed certificates created on IBM i, the client needs to trust the IBM i Certificate Authority certificate(s) used to setup Host Service encryption. IBM Navigator for i, the browser-based server configuration tool, includes the Digital Certificate Manager, which supports a number of encryption and authentication options for IBM i resources. For more information, refer to the DCM manual.

IBM i Setup

We will start with creating and assigning IBM i certificates to the database and data queue host servers using Digital Certificate Manager.

Point your browser to IBM Navigator for i at: http://your_ibmi_server_name:2001.

At the bottom of the left navigator menu, select the Internet Connection options, then select the Digital Certificate Manager (DCM) link on the main page.

Alternatively, point the browser directly to DCM at: http://your_ibmi_server_name:2001/QIBM/ICSS/Cert/Admin/qycucm1.ndm/main0

The screenshots below may have a bit different look and feel depending on IBM i version, but the essential functions stay the same.

Click on Select Certificate Store and select *SYSTEM.

If there's no *SYSTEM store available, create one by clicking on Create New Certificate Store and following the prompts. When creating the store, choose to not create the certificate yet.

Create a new Local Certificate Authority if one is not already created. Follow the prompts to create a new Local CA. Get to the page where the system asks to create *OBJECTSIGNING store and press Cancel.

Click on the Select Certificate Store button again to switch back to *SYSTEM store.

Now we are ready to create new certificate for encrypting host server communications. Click on Create new Server or Client certificate and use Local Certificate Authority for signing. Follow the prompts. On the Applications page, assign the newly created certificate to the servers that need to use this certificate for SSL connections, for example the database server, data queue servers, the remote command server, the sign-on server, and QIBM_HTTP_SERVER_<http server name>. For this demo, I just applied the certificate to all host servers.

Next, restart the host servers on IBM i so that the new certificate rules will take effect.

Mule Setup

Great, our IBM i server now supports secure communications! Next, in order to securely connect Mule to IBM i, we need to export and install the Local CA certificate.

In IBM i Digital Certificate Manager, select *SYSTEM certificate store, then click on Install Local CA Certificate on your PC, then select copy and paste certificate.

Copy / paste the certificate content into a text file <certificate file name> on your file system.

Create new truststore or import the certificate into an existing truststore:

keytool -import -alias IBMICERT -file <certificate file name> -keystore <truststore name>

Provide the store password and confirm that this certificate must be trusted.

In order to securely connect Mule to IBM i host servers via the encrypted channel, Mule JVM must use the truststore with the IBM i certificate. For on-prem deployments, the truststore can be saved anywhere on the Mule server, and for applications running on CloudHub, the truststore should be packaged as part of the application.

The quick and dirty way is just to pass the truststore name and password as JVM startup parameters in javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword. This option may not be ideal for production environments, as it globally sets the truststore for all Mule applications deployed to this on-prem runtime and would require quite a lot of jumping through hoops for CloudHub deployments.

Instead, we will import the truststore into the src/main/app folder of our application and set the default SSL context at application initialization to point to this truststore. This way, it will be consistent across on-prem and CloudHub deployments.

We will add truststore to the application SSL context at startup time using custom Java component defined in the Mule application:

<spring:beans>
    <spring:bean id="SSLBean" name="SSLBean"
        class="IBMiSSLDemo.CustomTrustStore">
        <spring:property name="pwd" value="qqqqqq12" />
        <spring:property name="path" value="${app.home}/truststore" />
    </spring:bean>
</spring:beans>

The Java class needs to implement org.mule.api.lifecycle.Initialisable and loads truststore as default SSL context in the initialise method:

public void initialise() throws InitialisationException{
try {
InputStream trustStream = new FileInputStream(path);
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
trustStore.load(trustStream, pwd.toCharArray());
TrustManagerFactory trustFactory = TrustManagerFactory
.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustFactory.init(trustStore);
TrustManager[] trustManagers = trustFactory.getTrustManagers();
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(null, trustManagers, null);
SSLContext.setDefault(sslContext);
} catch (Exception e) {
e.printStackTrace();
}
}

Data Queue and Command Call encryption

In most cases, the events that are passed via data queues just contain the transaction reference. The actual request and response data is staged in the IBM i database. For scenarios where sensitive data is passed via the queues or command calls, the the upcoming release of AS400 Connector introduces new configuration option "secureConnection". When set to true, the connector will encrypt the data when communicating with IBM i Host servers. The CA certificate used for protecting the Data Queue and Remote Command Call Host servers on IBM i side must be available to the Mule JVM where the application is executed.

<as400:config name="AS400__Configuration_type_strategy"
endpoint="${endpoint}" userid="${userid}" password="${password}"
doc:name="AS400: Configuration type strategy" libraryList="${libl}" secureConnection="true">

Secure Database Connection

The typical use case is to encrypt the data in transit for Mule database operations, including reading and writing the data as well as DB2 stored procedure calls. To enable the secure database connection, add jdbc parameter secure=true:

jdbc:as400://<ibm i server name>/<default library name>;secure=true

As with the AS400 connector setup, Mule must load the trusted CA certificate for IBM i Database host server.

To verify that Mule connects to IBM i via secure connection, look for job QZDASSINIT in the QUSRWRK subsystem, which handles SSL DB connections, as opposed to the QZDASOINIT clear text channel:

To recap, we enabled SSL encryption for IBM i Host Servers using the Digital Certificate Manager, then configured the Mule AS400 connector and database connector to communicate over that encrypted channel. Now we can securely connect Mule to the IBM i/As400 server for database use, data queue, remote command calls, and other TCP-based communications.

The source code for this demo and the developer preview version of AS400 connector 1.0.1, which includes SSL support, can be found at https://github.com/infoviewsystems/IBMi-Mule-SSL.