+

Search Tips | Advanced Search

Getting started with IBM MQ Internet Pass-Thru

The scenarios in this section show you how to set up some simple IBM MQ Internet Pass-Thru (MQIPT) configurations. We can also use these tasks to confirm that the product has been installed successfully.


Before starting

Before you start to use the scenarios in this section, make sure that the following prerequisites have been completed:

  • You are familiar with defining queue managers, queues, and channels on IBM MQ.
  • We have already installed an IBM MQ client and server.
  • MQIPT is installed in a directory called C:\mqipt on Windows systems. (The examples are written for Windows systems but will run on any of the supported platforms.) For more information on installing MQIPT, see Installing MQIPT.
  • The client, server, and each instance of MQIPT are installed on separate computers.
  • You are familiar with putting messages on a queue by using the amqsputc command.
  • You are familiar with getting messages from a queue using the amqsgetc command.
  • You are familiar with setting client authorities in IBM MQ.

On the IBM MQ server, complete the following tasks:

  • Define a queue manager called MQIPT.QM1.
  • Define a server connection channel called MQIPT.CONN.CHANNEL.
  • Define a local queue called MQIPT.LOCAL.QUEUE.
  • Start a TCP/IP listener for MQIPT.QM1 on port 1414. If port 1414 is already in use by another application choose a free port address and substitute it in the following examples.
  • Ensure that connection authentication and channel authentication is configured to allow client connections from the client machine with your user ID. If connection authentication is set to require a user ID and password for client connections, we will need to set the MQSAMP_USER_ID environment variable to the user ID to be used for connection authentication before running the amqsputc and amqsgetc commands.

After you have done this, we can test the route from the IBM MQ client to the queue manager by putting a message on the local queue of the queue manager, by using the amqsputc command, and then retrieving it, by using the amqsgetc command.

To prepare for the scenarios in this section, create and edit the mqipt.conf file as follows:
  1. Copy the mqiptSample.conf file, which we can find in the samples subdirectory of the MQIPT installation directory, to mqipt.conf in your chosen MQIPT home directory. The following scenarios use C:\mqiptHome as the MQIPT home directory.
  2. Create two directories alongside mqipt.conf named errors and logs. Set the file permissions on these directories so that they are writeable by the user ID that will run MQIPT.
  3. Delete all routes from the mqipt.conf file.
  4. In the remaining [global] section, check that ClientAccess exists and is set to true.


The following scenarios are described in this section:

  • Verify that MQIPT is working correctly
    Use this simple configuration setup to ensure that MQIPT is installed correctly.
  • Create a key ring file
    In this scenario, we can request a certificate and create a key ring file to allow MQIPT to use TLS.
  • Create test certificates
    In this scenario, we can create a self-signed certificate which we can use for testing MQIPT routes. This certificate can be used by an MQIPT route to identify itself to a remote peer.
  • Authenticating a TLS server
    In this scenario, we can test a TLS connection by using the test certificate in the sample (sslSample.pfx) key ring file, provided with MQIPT in the samples/ssl subdirectory of the MQIPT installation directory.
  • Authenticating a TLS client
    In this scenario, we can test a TLS connection by using the sample test certificate to perform server and client authentication.
  • Configure HTTP tunneling
    In this scenario, we can test a simple connection between two instances of MQIPT over HTTP.
  • Configure a HTTP proxy
    In this scenario, we can test the connection using a HTTP proxy (IBM Caching Proxy).
  • Configure access control
    In this scenario, we can set up your MQIPT to only accept connections from specific clients by using the Java Security Manager to add security checks on the MQIPT listener port.
  • Configure a SOCKS proxy
    In this scenario, we can make MQIPT act as a SOCKS proxy.
  • Configure a SOCKS client
    In this scenario, we can run MQIPT as though it was SOCKS-enabled, using an existing SOCKS proxy.
  • Configure MQIPT clustering support
    In this scenario, we can set up a clustering environment.
  • Allocating port numbers
    We can control the local port addresses used when making outgoing connections. For example, if your firewall allows only certain ranges of port numbers, we can use MQIPT to ensure that output originates from a valid port.
  • Retrieving CRLs by using an LDAP server
    We can configure MQIPT to use an LDAP server to retrieve certificate revocation lists (CRLs).
  • Running MQIPT in TLS proxy mode
    We can run MQIPT in TLS proxy mode, so that it accepts a TLS connection request from an IBM MQ TLS client and tunnels it to a IBM MQ TLS server.
  • Running MQIPT in TLS proxy mode with a security manager
    We can run MQIPT in TLS proxy mode, so that it accepts a TLS connection request from an IBM MQ TLS client and tunnels it to a IBM MQ TLS server. By using a security manager with MQIPT, we can restrict the addresses to which messages can be sent.
  • Apache rewrite
    In this scenario, we can use the rewrite directive to convert an HTTP request into an internal Apache proxy redirect.
  • Use a security exit
    In this scenario, we can use a supplied sample security exit, called SampleSecurityExit, so that only client connections that use a channel name starting with the characters MQIPT. are allowed.
  • Routing client connection requests to IBM MQ queue manager servers by using security exits
    In this scenario, we can dynamically route client connection requests, in a round-robin fashion, to a group of three IBM MQ queue manager servers. The queue manager on each server in the group must be identical.
  • Dynamically routing client connection requests
    In this scenario, we can dynamically route client connection requests to a target server, based on the name of the channel being used.
  • Use a certificate exit to authenticate a TLS server
    In this scenario, we can authenticate a TLS connection by using a certificate exit.

Parent topic: IBM MQ Scenarios

Last updated: 2020-10-04