On my previous 3-part blog, I showed how Mule ESB can be used to service-enable and orchestrate traditional on-premise technologies like an Oracle database and IBM Websphere MQ. Using Mule ESB, we created a service that accessed employee information from an Oracle database table and transmitted this to IBM WebSphere MQ. An observant customer I was showing this to noticed a security flaw with how sensitive employee information was being transmitted in plain text and also asked how the employee record can be sent to SalesForce.com. This blog will show how these can be easily addressed using MuleSoft’s AnyPoint Platform. We’ll make use of the PGP encryption features from AnyPoint Enterprise Security to encrypt the data before sending it to WebSphere MQ. Then, we’ll create another message flow to retrieve this message, decrypt it and send it to SalesForce.com using the AnyPoint Connector for SalesForce.com.
Part 1: PGP Encryption with AnyPoint Enterprise Security
First thing we’ll need to do is install the AnyPoint Enterprise Security module in Mule Studio by following the instructions here. After applying this update, you should see the security modules in your palette.
If you recall from my previous blog, the employee information was transmitted to WebSphere MQ in XML with plain text which we will now encrypt using PGP encryption.
In your flow, add the Encryption module from the Security group just before the WMQ endpoint.
Click the Config Reference + icon to add a Global Encryption configuration and set it to use the PGP_ENCRYPTER.
Click the Pgp Encrypter tag and define the attributes. You can download my pubring.gpg and secring.gpg files and use these for the Public Key Ring File Name and Secret Key Ring File Name. If you choose to do this, set the following:
- Set the Secret Alias Id to: 1551092709913607250
- Set the Secret Passphrase to: mulesoft
- Set the Principal to: mulesoft.
If you prefer to generate your own keys, you can use the gpg command-line utility which is available in Linux operating systems, as part of the GPG Keychain Access tool for Mac OS, or for Gpg4win for Windows. This screenshot shows how my keys were generated using the gpg command from a Mac OS. Note that the pubring.gpg and secring.gpg key files will be created in a hidden directory called .gnupg under the user home directory. For Windows, this will be in C:/Users/myuser/AppData/Roaming/gnupg directory.
The Principal will be the USER-ID which is a combination of the Real Name,Email Address and Comment in the format: Real Name (Comment) <Email Address>. To keep it simple, you can just use choose a simple Real Name and leave Email and Comment blank. In my example, I simply set the Real Name to mulesoft. I also set the Secret Passphrase to mulesoft.
Determining the numeric value for the Secret Alias Id is not obvious. The GPG utility does not show this numeric value. The best way to derive this is by letting Mule give you some clues. Put any random number initially for the Secret Alias Id and run it to let Mule throw an error on purpose. In the exception thrown from the Console output, you will see a message showing the keys you can use. (Thanks to this blog from Mariano Gonzales for these tips).
Save the flow. Clear the queue and run the flow again using SOAP UI the same way we tested from my previous 3-part blog. Now the data in the queue is encrypted as shown:
Let’s add a new flow that consumes the message from the queue and decrypts it. Drag the WMQ Endpoint under the previous flow to create a new one. Add an Encryption module (rename it to Decryption) to decrypt the message. Let’s also add a couple of Logger components to log the payload before and after the decryption.
For the WMQ endpoint, use the same queue name (QUEUE1) and WMQ connector used in the previous flow’s WMQ endpoint.
Log the message Before decryption: #[payload] on the first Logger and “After decryption: #[payload]” on the second Logger.
Save it and Run the Flow as a Mule Application (if it is not yet running). The flow should immediately pick up the encrypted message from the queue and then decrypt it. The console should show the log messages:
Part 2: SalesForce.com integration with the AnyPoint Connector for SalesForce
Add a Salesforce Global Element in the Config Reference.
You should have a SalesForce.com developer account with a Security Token. You can follow the instructions for registration and getting your security token here. Add your SalesForce.com username, password and security token in the Sales Force connection configuration.
Choose the Create single operation and the Contact sObject Type. Set the sObject Field Mappings to From Message: #[payload] as shown:
For the Input, choose XML. You can either use the XML you got from the Logger output to generate your XML schema by saving it in a file then clicking the Generate schema from xml link. Or, you can download the generated XSD from here.
Most of the fields should be automatically mapped. Just add a mapping from phoneNumber to Phone.
Also append + “@mulesoft.com”; to the email mapping as shown below since the data only has the email alias.
Using MuleSoft’s AnyPoint Enterprise Security, we are able to easily utilize encryption and decryption modules using industry standard approaches such as PGP to ensure that messages are protected as it gets transmitted across systems. Using MuleSoft’s AnyPoint Connectors and Data Mapper, we are able to easily transform and send the employee information to SaaS applications such as SalesForce.com. For more on MuleSoft’s AnyPoint Platform, check out: http://www.mulesoft.com/enterprise-integration-platform.