Use Advanced Message Security with Managed File Transfer

This scenario explains how to configure Advanced Message Security to provide message privacy for data being sent through a Managed File Transfer.


Before starting

Ensure that we have Advanced Message Security component installed on the IBM MQ installation hosting the queues used by Managed File Transfer that we want to protect.

If your Managed File Transfer agents are connecting in bindings mode, ensure you also have the GSKit component installed on their local installation.


When transfer of data between two Managed File Transfer agents is interrupted, possibly confidential data might remain unprotected on the underlying IBM MQ queues used to manage the transfer. This scenario explains how to configure and use Advanced Message Security to protect such data on the Managed File Transfer queues.

In this scenario we consider a simple topology comprising one machine with two Managed File Transfer queues and two agents, AGENT1 and AGENT2, sharing a single queue manager, hubQM, as described in the scenario Scenario overview. Both agents connect in the same way, either in bindings mode or client mode.

Parent topic: User scenarios


1. Creating certificates


Before starting

This scenario uses a simple model where a user ftagent in a group FTAGENTS is used to run the Managed File Transfer Agent processes. If we are using your own user and group names, change the commands accordingly.


About this task

Advanced Message Security uses public key cryptography to sign and/or encrypt messages on protected queues. Note:

  • If your Managed File Transfer agents are running in bindings mode, the commands that we use to create a CMS (Cryptographic Message Syntax) keystore are detailed in the Quick Start Guide ( Windows or UNIX ) for the platform.
  • If your Managed File Transfer agents are running in client mode, the commands we will need to create a JKS ( Java Keystore) are detailed in the Quick Start Guide for AMS with Java clients.


Procedure

  1. Create a self-signed certificate to identify the user ftagent as detailed in the appropriate Quick Start Guide. Use a Distinguished Name (DN) as follows: 
    CN=ftagent, OU=MFT, O=IBM, L=Hursley, ST=Hampshire, C=GB
  2. Create a keystore.conf file to identify the location of the keystore and the certificate within it as detailed in the appropriate Quick Start Guide.


2. Configuring message protection


About this task

We should define a security policy for the data queue used by AGENT2, using the setmqspl command. In this scenario the same user is used to start both agents, and therefore the signer and receiver DN are the same and match the certificate we generated.


Procedure

  1. Shut down the Managed File Transfer agents in preparation for protection using the fteStopAgent command.
  2. Create a security policy to protect the SYSTEM.FTE.DATA.AGENT2 queue. 
    setmqspl -m hubQM -p SYSTEM.FTE.DATA.AGENT2 -s SHA1 -a "CN=ftagent, OU=MFT, O=IBM, L=Hursley, ST=Hampshire, C=GB"
-e AES128 -r "CN=ftagent, OU=MFT, O=IBM, L=Hursley, ST=Hampshire, C=GB"
  3. Ensure the user running the Managed File Transfer Agent process has access to browse the system policy queue and put messages on the error queue. 
    setmqaut -m hubQM -t queue -n SYSTEM.PROTECTION.POLICY.QUEUE -p ftagent +browse
setmqaut -m hubQM -t queue -n SYSTEM.PROTECTION.ERROR.QUEUE -p ftagent +put
  4. Restart your Managed File Transfer agents using the fteStartAgent command.
  5. Confirm that your agents restarted successfully by using the fteListAgents command and verifying that the agents are in READY status.


Results

You are now able to submit transfers from AGENT1 to AGENT2, and the file contents will be transmitted securely between the two agents.