Securing WebSphere MQ File Transfer Edition V7

WebSphere MQ File Transfer Edition (FTE) is a new product from IBM that provides an enterprise-class platform for managed file transfer operations. Securing it requires an understanding of how the FTE components interact with both the file system and with WebSphere MQ. This article describes the component architecture and takes you through a sample use case that shows the network design and configuration tasks required to harden an FTE network.


T.Rob Wyatt, Senior Managing Consultant, EMC

T.Rob Wyatt is a Senior Managing Consultant with IBM Software Services for WebSphere who assists customers with the administration, architecture, and security of WebSphere MQ. Recently he has focused on WebSphere MQ security, publishing in the IBM WebSphere Developer Technical Journal and presenting at the IMPACT and European Transaction and Messaging conferences. T.Rob also hosts The Deep Queue, a monthly WebSphere MQ security podcast.

developerWorks Professional author

25 February 2009

Also available in Chinese Japanese


IBM® WebSphere® MQ File Transfer Edition, hereafter called FTE, integrates with an existing MQ network to add managed file transfer functionality. From an architectural perspective, FTE is constructed like any other WebSphere MQ application -- it connects to queue managers to put messages into or get messages from queues. In that respect it is secured through authentication and access control, much like any other MQ application. However, unlike most messaging applications, FTE crosses a security domain boundary from the messaging realm into the operating system's file and directory service. The security model for file and directory services differs greatly from that used by WebSphere MQ. An administrator must implement security that bridges both of these domains in a meaningful and effective manner, and therefore must provide for separation of duties between users and administrators, and in most cases enforce multiple end-user roles, each with distinct access rights.

This article describes the architecture of FTE to build an understanding of what needs to be secured and the security controls that are available. It then describes a use case requiring managed file transfer functionality for two departments in the same enterprise and the ability to enforce separate access controls for each department. The article closes with a checklist containing all of the tasks described in the article.

Component architecture

There are different versions of FTE, depending on whether it will connect to the queue manager in bindings or client mode. In addition to the functional components, each version also includes installation media containing remote tools and documentation packages. At configuration time, the administrator is asked to supply details of three queue managers known variously as the Agent Queue Manager, Command Queue Manager, and Coordination Queue Manager. It can be confusing to newcomers, but when you clear away the clutter it is quite simple. FTE is a single long-running daemon process called an agent, with tooling to let users submit commands to the agent and inquire on its status. Beyond that, everything else is just configuration details.

Figure 1 shows a typical installation of FTE without the queue managers drawn in. The diagram shows a sender agent and a receiver agent, each of which has its own command queue. File transfers are managed by users or administrators by placing messages onto the sending agent's command queue, either directly or with the supplied tooling. The agent processes respond to command messages, move files through WebSphere MQ, and then publish activity logs onto the SYSTEM.FTE topic. Users, administrators, and applications may then subscribe to the status updates on the SYSTEM.FTE topic.

Figure 1. WebSphere MQ File Transfer Edition components
Figure 1


Each FTE component requires access to a queue manager. In the simplest case, the users and agents can all connect to the same queue manager. At the other extreme, it is possible to distribute the agents and users across the network and let WebSphere MQ take care of routing the commands and data traffic between them. When discussing topologies, it is necessary to distinguish the different nodes based on their role. As noted above, they are referred to as Agent Queue Manager, Command Queue Manager, and Coordination Queue Manager.

Each FTE agent is associated with a single V6.0 or later queue manager. The agent and its queue manager may be hosted on the same server or the agent may use a WebSphere MQ client channel to communicate with a remote queue manager. When the agent is deployed, the administrator will create a set of queues for that agent to use. Because the queue names include the agent's name, it is possible for one queue manager to host multiple agents. For reasons explained later, this arrangement is quite common.

Command Queue Manager

FTE comes with command-line tools and an Eclipse plug-in to let users and instrumentation issue commands to the various agents in the network. In a small network with two agents connected to a single queue manager, the tooling can be configured to connect directly to that same queue manager. But in a distributed network with many agent queue managers, it is not practical or necessary to have the tooling connect directly to each agent queue manager to issue commands. Instead, the tooling is configured to connect to a single queue manager that has connectivity to all of the agents, relying on WebSphere MQ to route the command messages accordingly. Whichever queue manager the tooling connects to is referred to as the Command Queue Manager. There is nothing special about this queue manager other than that it can resolve a route to each agent queue manager. There is no FTE code required to run here and the only queues required are the temporary dynamic queues created by the tooling at run time. Any V6.0 or later queue manager will work. There is also no requirement that all users connect to the same Command Queue Manager and in fact the expected deployment would group sets of users by role onto different Command Queue Managers.

Coordination Queue Manager

The Coordination Queue Manager is the one thing all of the components in the FTE network have in common. Any significant event occurring at the agent results in a message published by the agent on the SYSTEM.FTE topic hosted on the Coordination Queue Manager. Any user or application that needs to know what's happening in the FTE network subscribes to these publications. Both the command-line tools and the Eclipse plug-in require a connection to the Coordination Queue Manager in order to consume publications. Agents have no such requirement, because the publications can be sent from the Agent Queue Manager across the WebSphere MQ network to the Coordination Queue Manager. There is no actual FTE code required to run on the Coordination queue manager. All of the work is accomplished using native WebSphere MQ functionality. FTE requires this queue manager to be at V7.0 or later because of the pub/sub features that are used, but other than that there is nothing special about this queue manager.

Deployment topologies

The simplest example of an FTE network is a single queue manager that serves as Agent Queue Manager, Coordination Queue Manager, and Command Queue manager all rolled into one. While this will work, it would not be very useful if it just moved a file from one directory on a server to another directory on the same server. To get the FTE network out of the lab and useable in the real world, the first thing to do is to distribute the agent processes onto the servers where files will be consumed or delivered. This results in the topology depicted in Figure 2, which has one queue manager and a network of three nodes where the agents are connected using WebSphere MQ client channels. The queue manager in this case serves simultaneously in all three roles of Coordination, Command, and Agent queue manager:

Figure 2. Small FTE network with a single queue manager
Figure 2

The small network shown in Figure 2 strikes a balance between administration, license cost and efficiency. Although the logical movement of the file is from Agent01 to Agent02, the physical data path flows through the queue manager. This results in the file transfers traversing two network hops – once from Agent01 to the queue manager and again from the queue manager to Agent02. There are fewer moving parts and only one MQ license but if there is a lot of FTE traffic, the network bandwidth consumed will be more than double the amount of actual data that is transferred.

A high-volume FTE network will address this problem by co-locating queue managers with the agents, as shown in Figure 3 below. In this topology, command and status messages still flow through a single queue manager serving as both Coordination and Command Queue Manager, but data flows directly between the two Agent Queue Managers over WebSphere MQ channels such as a Sender/Receiver pair.

Figure 3. Distributed FTE network with local Agent Queue Managers
Figure 3

This distributed topology will be used to illustrate the discussion through the remainder of the article because it provides a context to examine security configurations of both client and queue manager-to-queue manager connections. A subset of the same techniques could be used to secure the simpler case where all components are deployed to a single queue manager.

File and operating system security

Application or infrastructure?

There is a contextual question here as to whether the FTE agent is a business application or an infrastructure component of WebSphere MQ. If we treat FTE as a business application, then the solution is simply to run it under the application's service account and authorize that account to WebSphere MQ the same as any other non-administrative application. This grants the FTE agent access to read, delete, and create application files as required, and do so with minimal security rights to WebSphere MQ. This does however mean that maintenance and support of FTE is distributed among the various application support teams who in turn must maintain a certain level of WebSphere MQ administrative skill and coordinate with each other to insure that the FTE configurations are compatible. Not only does this not scale well, but it conflicts with some of the goals of an enterprise-managed file transfer solution, which include central administration and provision for separation of duties between administrators and end users. Many shops will want to follow a least-privileged security model for regulatory compliance or simply because it is good practice. Achieving separation of duties is key to implementing this least-privileged model, so the configuration discussed here implements the FTE agent under its own service account with limited access to WebSphere MQ and to the business application files and processes.

FTE operates on UNIX, Windows, and z/OS, and each of these has its own security mechanisms. With z/OS, access is based on qualifiers in the file name, and it is relatively easy to create profiles that let FTE exchange files with end users based on common high-level qualifiers in the file names, so this is left as an exercise for the reader. On Windows or UNIX, however, access is based on file ownership, directory ownership, and group affiliation. Some mapping of ownership and privileges is therefore necessary in order to get the fine-grained access required. The goal is to devise a set of access rules such that:

  • The FTE agent is the only account that can get to the FTE executables and configuration files
  • Both the agent and the end users can read, write, and delete the files that will be transferred
  • Only the business accounts have access to other business assets such as application configuration files

File creation and ownership

When the FTE agent delivers a file, the file ends up being owned by the FTE service account, and end users do not automatically have access to it. On UNIX, the umask attribute can be set to cause newly created files to be world-writeable, which solves the problem, but hardly qualifies as following the principle of least-privileged access. A better approach is to set umask such that new files are group-writeable and grant access by group. But what group should be used?

The new file's group attribute inherits from the owner's primary group. If we are to use group affiliation as the mechanism to share access rights, then the primary group of the FTE service account cannot be a private group, but must contain at least one end user or application service account. This gives the end user or application the ability to read and delete the files that the FTE agent creates at run time. This results in a set of requirements that include an administrative service account for the FTE agent, configured with a primary group containing one or more business accounts.

This secures the run-time files but it may leave the build-time files exposed. If the FTE service account was used to perform the installation, then the installation files will be owned by the same group that contains the non-administrative accounts. This enables end users and business applications to read, write, and delete FTE system and configuration files. To resolve this problem, the group affiliation of the FTE system files should be changed to some group other than the FTE service account's primary group. The FTE service account should be enrolled as a secondary member of this group.

In order to move files in the opposite direction, where they are created by the business user and consumed by the FTE agent, a similar mapping of primary and secondary groups must occur on the application service account. In this case, the goal is to give the FTE agent access to files created by the business account for transfer somewhere else, but not grant the FTE agent access to business assets such as application configuration files. This imposes an additional requirement that the service accounts for the FTE agent and the business users must both have the same primary group in order to allow bi-directional read/write access to each other's files.

An example mapping of accounts and groups is shown in Figure 4:

Figure 4. Mapping of accounts and their primary and secondary groups
Figure 4

On Windows, ownership of new files inherits from the creating user, just as on UNIX, but the file does not have group ownership in the same sense as a UNIX file does. Fortunately, the same access model of group affiliations works equally well on Windows, as long the fteuser group is granted full access to the folder that will contain the new files. Although it would be possible in Windows to set up the authorizations based entirely on user ID permissions, it is better to use the group model described above because it works across both platforms.

Running the FTE agents

FTE agents do not require administrative authority to the queue manager. Unfortunately, defining a WebSphere MQ service to start the FTE agent confers administrative authority because the agent is started as a sub-process of the queue manager. The danger here is not so much that the FTE agent could be used to manipulate MQ objects, but rather that it could be used to overlay the WebSphere MQ configuration files. For example, in the default configuration, an FTE agent running as mqm could be commanded to fetch the qm.ini file. The attacker could edit qm.ini to disable the Object Authority Manager and then use the same FTE agent to overlay the legitimate qm.ini with the doctored one. The next time that the queue manager is booted, all security will have been silently disabled. The best way to avoid this kind of attack is to create a service account for the FTE agent to run under and exclude that service account from the mqm group.

The sandbox

The sandbox feature lets the administrator designate a directory anywhere in the file system as the root directory or the FTE agent. Any attempt to access files outside the sandbox will be refused. The sandbox is enabled by editing the file and adding the sandboxRoot property with a value equal to the fully-qualified directory name of the designated directory.

The attack described above, where the FTE agent is coerced into overlaying critical server configuration files, assumes that the agent has been installed with the default settings. In particular, the sandbox feature must have been left disabled in order to execute this kind of attack. Does that mean enabling the sandbox eliminates the requirement for a dedicated service account to run the agent under? That depends on the security requirement. Following the principle of defense in depth, the strong recommendation is to implement both the sandbox feature and the service account segregation. If an attacker were to discover a vulnerability in the agent, the configuration would fail to a relatively secure state rather than exposing administrative privileges. Enabling the sandbox should be considered mandatory for any FTE installation, as would basic file system security.

The sandbox property is a single value and not an array. If there are multiple directories for delivery or consumption of files, you must configure a different agent for each directory, each with the appropriate sandbox property value.

Preventing file forwarding attacks

One final note about the configuration files concerns the agent's ability to both read and write end-user data. The attack described against the qm.ini file depends on the availability of a read/write-capable agent. In a network with more than two agents, a similar attack would deliver a file to an intermediate agent and then cause that agent to relay the file to a third agent to which the attacker does not have direct access. Because agents communicate with each other using the same command queue as end users, this cannot be prevented by blocking access to the remote agent's command queue. What you can do however, is configure the agents to be read-only or write-only by once again editing the file. Setting the maxSourceTransfers property to zero causes the agent to refuse to transfer outbound files. Similarly, setting the maxDestinationTransfers property to zero causes the agent to refuse to accept inbound files. Although it is syntactically correct to set both of these values to zero, it is not recommended as it completely disables the agent from transferring any files. If two agents are deployed on a server, with one as a file sender and one as a file receiver, configuring them so that their sandbox directories do not overlap provides protection against a file relay attack.

Base MQ security for the agent queue manager

Anyone with administrative access to the Agent Queue Manager can drive any actions that the agents there are configured to perform. Clearly, securing the queue manager from administrative access is a prerequisite to securing the FTE agent. A complete discussion of securing a queue manager is beyond the scope of this article, but here is a brief overview. For more information on WebSphere MQ security, see Resources at the bottom of the article.

For local users connecting to the queue manager using bindings mode (shared memory rather than a SVRCONN channel), the operating system authentication is sufficient. For these users, the prescription is to exclude them from the mqm group and grant appropriate permissions to queue manager objects using setmqaut commands.

The real challenge is securing remotely connected users and connections from other queue managers. Any inbound channel that does not have a low-privileged account in the MCAUSER attribute is capable of administering the queue manager and the FTE agent. The strategy for securing remote connections is to strongly authenticate the connection request and then ensure that an MCAUSER value corresponding to the authenticated identity is configured for the channel.

The first step in securing any queue manager is to disable any inbound channels that should not legitimately be used, by setting MCAUSER('nobody') for any SYSTEM.DEF.* and SYSTEM.AUTO.* channels.

The SYSTEM.ADMIN.SVRCONN channel is commonly used by administrators and end users alike to access the queue manager with WebSphere MQ Explorer. Typically, these connections are authenticated using SSL certificates, and a channel security exit such as BlockIP2 is then used to dynamically map the SSL certificate to an MCAUSER value for that channel instance. In this way, many users can simultaneously and securely access a single channel definition using a variety of MCAUSER values. In this configuration, the channel is normally defined with MCAUSER('nobody') or another low-privileged account, so that if the exit fails, the channel is not exposing administrative privileges.

Alternatively, the same level of security can be obtained without using an exit by judicious use of SSLPEER and SSLCAUTH on the channel and a static MCAUSER value. With this strategy you must define multiple SVRCONN channels, one for each security role. For example, administrators would use one channel with MCAUSER('mqm') or MCAUSER(' '). End users would connect through one or more additional channels where MCAUSER was configured with a non-blank value corresponding to a low-privileged account. In any of these secure configurations, interactive users are authenticated using SSL. The channel's SSLCAUTH attribute is enabled to force the user's MQ client to provide a certificate and any unused certificate authorities are removed from the queue manager's SSL keyring.

In addition to securing client connections, you must also secure inbound MCA channels, including channels of type RCVR, RQSTR and CLUSRCVR, because these channels expose administrative access if left in their default settings. The exposure is addressed by provisioning a service account along with a private group. The MCAUSER attribute of the channel is configured with the account name. Next, the group is authorized for connect and inquire to the queue manager and to put and inquire on a limited number of legitimate destinations. The group is specifically denied access to queues that can be used to obtain administrative privileges, such as the Command Queue, any transmit queues, and any initiation queues.

In a cluster, this configuration requires both a Channel Auto-Definition exit and a Security exit. The CHAD exit configures the security exit which, in turn, sets the MCAUSER attribute of the channel to the appropriate service account.

For more information on securing queue managers from administrative access, see:

WebSphere MQ security for the FTE agent

Let's review what we have done so far:

  • The WebSphere MQ FTE agent is running under a dedicated service account with a common group and a private group.
  • The agent has been authorized with read and execute access to its own directories.
  • The file depot directory has been created under the ownership of the business user account.
  • The agent sandbox is enabled and points to the file depot directory.
  • The agent has been granted read/write/delete access to the file depot directory.
  • The Agent Queue Manager authenticates all connections and restricts administrative authority from low-privileged users.

The next step is to secure the WebSphere MQ objects that are used by the FTE application. In order to do that, you need to understand the protocol used to drive the activities of the agent.

Administrators, end users, and other agents all interact with the FTE agent by placing messages into its Command Queue. The agent does not make any distinction between the command messages received from administrators and other agents versus the command messages received from end users. Security thus is based strictly on the ability to place messages onto the agent's command queue, and anyone with this level of access can drive any actions that agent is configured to perform.

Since the interactive tools all drive file transfers from the sending side, one obvious way to enhance security is to block end user access to the receiving agent. In the network shown in Figure 3 above, administrative commands between interactive users and agents flow over different channels than agent-to-agent communication. By placing different MCAUSER values on the channels, you can let AGENT01 place messages on the Command Queue of AGENT02 while simultaneously blocking users on the Command Queue Manager from placing messages on the same queue. Figure 5 below shows how access to the command queue might be controlled based on the message path. This security enhancement is dependent on the ones already mentioned. In particular, AGENT01 must be configured as a send-only agent and the end user must not have access to the transmit or other administrative queues on AGENT01's queue manager -- otherwise the end user could simply relay a doctored file through AGENT01 or send it directly to AGENT02.

Figure 5. Securing access to the agent command queue based on message path
Figure 5

Agents also communicate through each other's SYSTEM.FTE.REPLY.<agentname> queues. For this reason, the channels between AGENT01 and AGENT02 must be authorized to place messages on each other's reply queues whereas the channels from the Command Queue Manager will be specifically forbidden from placing messages on the agent reply queues, if we are following a least-privileged model.

Coordination Queue Manager

As mentioned earlier, any V7 queue manager can be designated as the Coordination Queue Manager. All of the agents in an FTE network publish updates to the same Coordination Queue Manager and any applications or tools connect to the coordination queue manager in order to subscribe to the agent publications. The V7 Queue Manager can accept V6.0 style publication messages on a queue and convert these to a V7 topic. This is what makes it possible to deploy FTE agents on V6.0 queue managers, but the arrangement does have some security ramifications.

When the Coordination Queue Manager is configured, a queue named SYSTEM.FTE is defined. Next, the name SYSTEM.FTE is added to a special system namelist and this causes the queue manager's pub/sub engine to monitor the new queue for publication messages. At this point, any properly formatted RFH2 messages landing on the SYSTEM.FTE queue are converted to V7 publications. There are two security checks performed in this process. The first is physical access to the queue. In our example, the Coordination Queue Manager is remote to all of the agents in the network so the thing putting messages on the queue is a message channel agent. As part of the base queue manager hardening, the channel's MCAUSER attribute was configured with a low-privileged user ID. The private group containing the user ID in the channel's MCAUSER is what needs to be authorized to place messages onto the SYSTEM.FTE queue.

The next security check is that the user ID contained in the MQMD.UserID field of the message header must be authorized to publish on the SYSTEM.FTE topic. This is similar to the authorization check that the queue manager's command server performs before executing PCF commands and is the reason why the base security hardening is required – the value in the MQMD.UserID cannot be trusted if the agent or ordinary users and applications have administrative rights anywhere in the network. That means authenticating the agent's connection and then providing a secure path from the agent to the coordination queue manager. For agents that connect in bindings mode, the MQMD.UserID value will be the service account that the agent is running under. For agents connecting in client mode the MQMD.UserID will contain the value inherited from the SVRCONN channel's MCAUSER. These values remain intact in the message as it moves from the Agent Queue Manager to the Coordination Queue Manager where the security check occurs. The trick will be to insure that when the messages arrive from various agents distributed throughout the network, all of the MQMD.UserID values will pass an authorization check for publication to SYSTEM.FTE.

There are several strategies that will work here. If the FTE components are deployed on a small closed network, physical access control over the SYSTEM.FTE queue may be sufficient. To qualify, all of the inbound channels on this queue manager would have MCAUSER values that restrict access to the SYSTEM.FTE queue so that only agents could put messages there. The SYSTEM.FTE topic could then be authorized for anonymous publication. This strategy works best if the network uses classic channels because a cluster would not provide the ability to apply security on a per-connection basis without sophisticated channel exits. This strategy is also favored when agents are running under a large number of unique service accounts.

Another alternative is that every service account provisioned for an agent must also be defined on the coordination queue manager and authorized to publish to the SYSTEM.FTE topic. This strategy is favored if the FTE network is deployed using WebSphere MQ clustering since all nodes in the cluster will have access to place messages onto the SYSTEM.FTE queue. This strategy tends to favor reuse of the agent service account across agent instances to minimize the number of IDs that must be defined on the coordination queue manager. In this configuration, every agent service account is defined on the agent's host server and also on the server hosting the Coordination Queue Manager. Once defined, the accounts are placed into a group that has access to the SYSTEM.FTE queue on the Coordination queue manager.

Finally, it is possible to configure the agent to set the MQMD.UserID in its publications to any arbitrary value. The publicationMDUser property in the file controls this behavior. With this strategy it is possible to run the agent under one user ID and have it publish messages under another. In a large FTE network where each agent has a unique service account, this setting allows them all to publish messages using the same identity. Although this sounds like an ideal solution, it does require the agent to have a certain amount of administrative authority. In general, it is not recommended to grant any user the ability to set the MQMD.UserID. If an account with this privilege is compromised there is nothing to prevent an attacker from setting the MQMD.UserID to a value corresponding to an administrative account such as mqm. If the attacker can then address that message to a queue manager's command queue, that queue manager is fully compromised. Since FTE agents rely on direct access to the transmit queue leading to the Coordination Queue Manager, allowing them to set MQMD.UserID effectively grants them administrative access to the Coordination Queue Manager. If this were acceptable, none of the other security configuration described in this article would be necessary. Do not use this feature as a security control.

Additional considerations

The role of topology as a security control

We have seen that the WebSphere MQ side of FTE is secured like any other MQ application. Queue security is based on service accounts and groups. In a typical network, access to FTE agents will occur through remote connections and portions of the security policy are implemented through the physical connectivity of the messaging network. To the extent that different access roles are required, these are governed by distinct service accounts in the MCAUSER attributes of the various channels. Thus far these architectural aspects have suggested a topology that provides separate paths for interactive commands versus inter-agent commands. It has also resulted in the partitioning of agents into send-only and receive-only pairs and a prerequisite that the queue managers involved have all been hardened against administrative privilege escalation.

Most shops will not have implemented this level of security in their existing WebSphere MQ network. For example, if the agents were placed into a WebSphere MQ cluster where users were routinely granted access to the cluster transmit queue, any user could drive any FTE agent. Although it is too early to say that a best practice has emerged, it is anticipated that creation of small closed networks of FTE agents and users will be a common deployment pattern. The FTE queue managers may be created alongside existing queue managers so that new WebSphere MQ installations are kept to a minimum, but it will be easier to secure a new, small, closed network than to retrofit security into a large existing network supporting many critical applications.

The security roles discussed thus far have included administrators, end users and agents. But a typical requirement will be to have several different classes of end users and a granular security model that enforces restrictions against these users accessing each other's files. We have already seen that FTE security is expressed largely through the physical topology of the network and a small closed network is one way to provide separation of duties between administrators and end users. Expanding on that model to provide granularity among end user roles can be achieved by building multiple closed FTE networks. For example, there might be one FTE network for Personnel and another for Payroll.

What about security exits?

The security exit points provided in this version of the product allow interception of the file transfer operations themselves. There is no exit point that intercepts commands so it would not be possible to authenticate command messages with an exit. Because of this limitation in the current product, the creation of closed networks of FTE agents is still the best method of insuring that only legitimate users can place messages on the agent's command queue.

Advanced topologies

Assuming that separate closed networks of FTE agents are required to support a granular security model, how can files be exchanged securely across two of these closed networks? Again, it is too early for best practices to have emerged but it is anticipated that this need will be met using overlapping sandboxes. For example, if Personnel needs to send a new Employee Master file to Payroll, this can be accomplished by having agents from both departments using different agent queue managers but with their sandboxes configured to point to the same directory. Although files in the sandbox would be accessible to both agents, the agent command queues would be on separate queue managers and accessible only to their respective departments. The overlap of access is thus restricted to the file system which exposes a minimal attack surface and avoids the complication of implementing fine-grained access control over the agent command queues.

Another case of an advanced topology would be a B2B FTE network that crosses enterprise boundaries. The recommended topology for any B2B WebSphere MQ network is that external connections terminate on a hardened gateway from which messages relayed to the internal server. An additional recommendation for B2B interfaces is to allow connections from queue managers only – no clients. Both of these recommended practices argue against allowing a business partner use the MQ FTE client agent to connect to an internal file server. Instead, the recommended solution would be two agents, each inside their enterprise's respective internal network and each routing messages through hardened MQ gateways. Although this adds two hops between the respective Agent Queue Managers, it is exactly the same network topology that is recommended for any other B2B interface.

Updating the FTE configuration files

Several of the configuration steps mentioned require changes to the agent configuration files. Remember to restart the agent after modifying the file, otherwise it will not pick up the new values. Be sure to check the agent log file to verify that the new configuration has been parsed correctly. In particular, the agent does not tolerate trailing blanks or any other whitespace after the last character in a property value.

FTE Security task list

The list below summarizes the tasks described in this article. They are subject to change because there are not yet enough installations of FTE for definitive best practices to emerge, and in addition the product will continue to evolve.


  1. Determine the different security roles required among end users.
  2. Determine the topology of the FTE network or networks to support the end user security roles.
  3. Map out the file transfer flows and identify agents as read-only, write-only or read/write capable.
  4. Identify the strategy that will be used to authorize publications on the Coordination Queue Manager.
  5. Based on the information in the above steps, identify the service accounts and groups to be created, noting the users to be enrolled in each group, which groups are primary and which groups are secondary.

Agent installation

  1. Provision a service account, a common group and a private group for the WebSphere MQ FTE agent.
  2. Install the agent on the server.
  3. On UNIX systems, the group affiliation of the FTE installed files will be the primary group of the account that performed the installation. Change the group of the installation files to the private (i.e. secondary) group of the FTE service account.
  4. Mark the FTE installation and configuration files as read-only, excluding of course the log files, trace files, or any other other files written to at run-time.
  5. If the installation was performed by an account other than the FTE service account, change the file ownership of the FTE installation files at this time as well.
  6. Grant read/write/delete privileges to the FTE common group for the directory that end user files will be delivered to or consumed from.
  7. Add end user or application accounts to the FTE common group.
  8. Edit the file. Insert the sandboxRoot property and set its value equal to the fully-qualified path name of the end-user file directory.
  9. If the agent is to be read-only, add the maxDestinationTransfers property to the file with a value of 0.
  10. If the agent is to be write-only, add the maxSourceTransfers property to the file with a value of 0.

Base queue manager hardening

  1. Alter all SYSTEM.DEF.* and SYSTEM.AUTO.* channels with MCAUSER('nobody').
  2. Provision two service accounts and private groups. As described in Hardening WebSphere MQ Security, we will refer to the ID used in RCVR, RQSTR and CLUSRCVR channels as mqmmca and the account used in SVRCONN channels as mqmmqi.
  3. Alter all user-defined RCVR, RQSTR and CLUSRCVR channels with MCAUSER('mqmmca').
  4. Alter all user-defined SVRCONN channels with MCAUSER('mqmmqi').
  5. Grant the mqmmca and mqmmqi groups access to all the queues except for the administrative ones, including the command queue, initiation queues, transmit queues, and pretty much all SYSTEM.* queues.

This is the minimum base security configuration for all queue managers. All it does is to restrict administrative rights to the queue manager. All other WebSphere MQ security builds from this base configuration and, in particular, the ability to grant different access rights on a per-connection basis will require more than two static MCAUSER values.

MQ hardening for FTE agents

  1. For any agent to which a legitimate user can connect and submit transfer requests, identify the channels that user commands will arrive on and authorize these to place messages onto the SYSTEM.FTE.COMMAND.<agentname> queue. This can be by means of a static MCAUSER in the channel definition or a channel security exit that sets the MCAUSER. Any channel with a blank MCAUSER exposes administrative authority to the FTE agent and to the queue manager itself.
  2. Authorize the agent's public group (fteuser in the example) to the SYSTEM.FTE.COMMAND.<agentname> queue.
  3. Insure that the user ID configured in the channel's MCAUSER in Step 1 is a member of the group authorized in Step 2.
  4. Authorize the agent's private group to all SYSTEM.FTE.* .<agentname> queues.
  5. If the agent is connecting through a client channel, insure that the channel authenticates the connection using SSL and that the authenticated identity ends up in the MCAUSER field.
  6. Insure that any inbound channels leading to other agents are authorized to put messages onto the local agent's command and reply queues. If there are several agents in the network or multiple agents locally, this may involve creation of multiple sets of channels and multiple user IDs for the MCAUSER settings.

MQ Hardening for the Coordination Queue Manager

  1. If anonymous publication is to be used, grant the group "nobody" access to the SYSTEM.FTE topic. The specific string "nobody" is significant to WebSphere MQ and represents an unauthenticated user.
  2. Alternatively, create a group called fteagents (note the plural).
  3. Authorize the fteagents group to the SYSTEM.FTE topic.
  4. For each service account that an agent runs under, create an account by the same name on the server hosting the Coordination Queue Manager and enroll that account in the fteagents group.
  5. Crate a SVRCONN channel for interactive users to connect over with the Eclipse plug-in.
  6. Set the MCAUSER of the new SVRCONN channel to a user ID that is authorized to subscribe to the SYSTEM.FTE topic.

MQ Hardening for the Command Queue Manager

Recall that the Command Queue Manager is nothing more than a connection into the network for the FTE tooling. Since the focus of most of the security configuration is on the inbound side of the connection, there is not much to do here beyond making sure the queue manager is not administratively compromised.

  1. Apply the base MQ hardening techniques so that users are authenticated and held to non-administrative access.
  2. Ensure that the Command Queue Manager has channels only to agents configured to send files.


Although FTE provides some useful security tools, such as the sandbox feature, most of the security configurations are external to the FTE components. These include the use of special service accounts and groups, a deployment topology consisting of closed networks, and a prerequisite to harden the underlying queue managers to restrict administrative access. Where there is a requirement for multiple end user roles, this level of granularity will require isolated closed FTE networks, one per end user role. Interaction between FTE networks will be through the file system rather than the messaging network, because this minimizes the security exposure. These recommendations will evolve as the product matures and with the benefit of more field testing. No guideline can be called a best practice until it has withstood the test of time and these are no exception. Finally, the configuration tasks described in this article were collected into a concise task list, which should be used as a starting point to adapt based on your individual requirements and experience.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Securing WebSphere MQ File Transfer Edition V7