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, and 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:
- IBM i (AS/400) 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 IBM i Certificate Authority certificate(s) used to setup Host Service encryption. IBM Navigator for i, the browser based server configuration tool, includes Digital Certificate Manager that supports a number of encryption and authentication options for IBM i resources. For more information refer to DCM manual .
IBM i setup
We will start with creating and assigning IBM i certificate to 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 Internet Connection options, then select 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 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 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 a new certificate for encrypting the Host server’s 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, Database server, Data Queue server, Remote Command server, Signon server, and QIBM_HTTP_SERVER_<http server name>. For this demo, I just applied the certificate to all host servers.
Next, Restart host servers on IBM i so that new certificate rules will take an effect
Mule Client 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 the certificate
Copy/paste the certificate content into a text file <certificate file name> on your file system.
Create a new truststore or import certificate into existing truststore
[code]
keytool -import -alias IBMICERT -file <certificate file name> -keystore <truststore name>
[/code]
Provide store passwords and confirm that this certificate must be trusted.
In order to securely connect Mule to IBM i Host Servers via an encrypted channel, Mule JVM must use the truststore with 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 to pass truststore name and password as JVM startup parameters 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 the hoops for CloudHub deployments.
Instead, we will import truststore into 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 a custom Java component defined in the Mule application:
[code] <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> [/code]
The Java class needs to implement org.mule.api.lifecycle.Initialisable and loads truststore as default SSL context in the initialise method:
[code] 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(); } [/code]
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 upcoming release of IBM i (AS/400) Connector introduces a 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.
[code] <as400:config name="AS400__Configuration_type_strategy" endpoint="${endpoint}" userid="${userid}" password="${password}" doc:name="AS400: Configuration type strategy" libraryList="${libl}" secureConnection="true"> [/code]
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:
[code] jdbc:as400://<ibm i server name>/<default library name>;secure=true [/code]
As with IBM i (AS/400) connector setup, Mule must load the trusted CA certificate for IBM i Database Host server.
To verify that Mule connects to IBM i via a secure connection, look for job QZDASSINIT in QUSRWRK subsystem, that handles SSL DB connection, as opposed to QZDASOINIT clear text channel:
To recap, we enabled SSL encryption for IBM i Host Servers using Digital Certificate Manager, then configured Mule IBM i (AS/400) connector and Database connector to communicate over encrypted channel. Now we can securely connect Mule to IBM i / As400 server for the database, data queue, remote command call, and other TCP based communications.
The source code for this demo and the developer preview version of IBM i (AS/400) connector 1.0.1 that includes SSL support can be found at https://github.com/infoviewsystems/IBMi-Mule-SSL
Recent Comments