MQ Intercommunication
Version: 1.0
Date 2008-06-10
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
Table of Contents
1
INTRODUCTION ........................................................................................................................................ 3
1.1
1.2
1.3
1.4
1.5
2
PURPOSE .................................................................................................................................................. 3
AUDIENCE ............................................................................................................................................... 3
VERSION HISTORY ................................................................................................................................... 3
REFERENCE DOCUMENTS ......................................................................................................................... 3
ABBREVIATIONS ...................................................................................................................................... 3
MQ TO MQ COMMUNICATION ............................................................................................................. 4
2.1
2.2
INFORMATION NEEDED .................................................................... ERROR! BOOKMARK NOT DEFINED.
SECURITY ................................................................................................................................................ 5
2 (7)
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
1 Introduction
1.1 Purpose
The purpose of this document is to describe the MQ intercommunication between
Region Syddanmark and external parties.
1.2 Audience
Integration Center at Region Syddanmark.
1.3 Version history
Version
Date
Description/comments
Responsible
0.1
2008-06-10
Initial draft
John Torgersson
1.4 Reference documents
Document name
Issued by
1.5 Abbreviations
Abbreviation
Meaning
WMQ
WebSpher MQ
QM
Queue Manager
3 (7)
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
2 WMQ to WMQ Communication
2.1 Remote Communication
Sender
The following needs to be created on the sending Queue Manager:

Define the message channel to the sending system

Create the transmission queue

Define the remote queue object to resolve the queue name used by applications to
the desired destination queue name, destination queue manager name, and
transmission queue name
In order to do this the following information is needed from the receiver:

IP address

Port number

Queue manager name

Queue name
Receiver
The following needs to be created on the receiving Queue Manager:

Message channels to receive messages from sending queue manager

The local queue

User access to the local queue.
In order to do this the following information is needed from the sender:

Sender user name
If SSL is used the sender and receiver has to exchange certificates.
Information about the Queue Manager can be found here:
http://techwiki.regionsyddanmark.dk/display/baseline/QueueManagers
4 (7)
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
Queue name will be present in the integrations implementation.
2.2 Security
Firewall
When a MQ connection should pass a firewall, ports 1414 and 1881 should be used.
These are the ports assigned to WMQ by IANA (see
http://www.iana.org/assignments/port-numbers).
Users and MQ object authorization
Users belonging to the system administrators (e.g. root, Administrators) and those in
the mqm group gets administrative access to MQ. Therefore, only users with absolut
needs for administrative access should be allowed in the mqm group. Application users
should never be placed in the mqm group.
On Windows, applications running a the Local system (SYSTEM) user is allowed full
administrative access to MQ. It is therefore not recommended to allow applications to
run as Local system when connecting to MQ.
For application users, it is recommended to create a application group (e.g. mqappname), place the application users in the group and set MQ authorizations for the
group. Applications must not have access to any SYSTEM.* queues unless for JMS
publish/subscribe as defined below.
If the queue manager is dedicated for an application, access can be given to all non
SYSTEM queues, for example:
setmqaut -m QM1 -t qmgr -g mq-appa –all +connect +inq
setmqaut -m QM1 -t queue -n ** -g mq-appa –all +browse +get +inq +put
setmqaut -m QM1 -t queue -n SYSTEM.** -g mq-appa –all +none
If the application is hosted on a shared queue manager, set up access rights for the
queues needed by the application, for example:
setmqaut
setmqaut
setmqaut
setmqaut
-m
-m
-m
-m
QM1
QM1
QM1
QM1
-t
-t
-t
-t
qmgr -g mq-appa –all +connect +inq
queue -n ZYS001** -g mq-appa –all +browse +get +inq +put
queue -n ZYS002** -g mq-appa –all +browse +get +inq +put
queue -n SYSTEM.** -g mq-appa –all +none
If the application uses JMS publish/subscribe, it also needs to following access granted:
setmqaut -m QM1 -t queue
+browse +get +inq +put
setmqaut -m QM1 -t queue
+get +inq +put
setmqaut -m QM1 -t queue
+get +inq +put
setmqaut -m QM1 -t queue
+browse +get +inq +put
-n SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE -g mq-appa –all
-n SYSTEM.BROKER.CONTROL.QUEUE -g mq-appa –all +browse
-n SYSTEM.BROKER.DEFAULT.STREAM -g mq-appa –all +browse
-n SYSTEM.JMS.ND.SUBSCRIBER.QUEUE -g mq-appa –all
5 (7)
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
Binding vs client
When applications connect to WMQ, it can choose between binding or client transports
types. Binding connects the application directly to the MQ process and thus only works
if the application and MQ is installed on the same server. Client connect the application
using TCP/IP and therefore supports connecting to a remote queue manager. Binding is,
from a security standpoint, allways preferred to client when the application and the
queue manager is installed on the same server. When using binding, no channel or SSL
configuration is needed.
Channels
By default, WMQ creates the following channels:
SYSTEM.AUTO.RECEIVER
SYSTEM.AUTO.SVRCONN
SYSTEM.DEF.CLUSRCVR
SYSTEM.DEF.CLUSSDR
SYSTEM.DEF.RECEIVER
SYSTEM.DEF.REQUESTER
SYSTEM.DEF.SENDER
SYSTEM.DEF.SERVER
SYSTEM.DEF.SVRCONN
SYSTEM.DEF.CLNTCONN
For remote administration, SYSTEM.ADMIN.SVRCONN, is commonly created.
However, this should normally not be allowed and should be removed if existing.
An application can use these channels to gain illegal access to a queue manager. All the
default channels (except SYSTEM.DEF.CLNTCONN) must therefore be closed directly
after installation of the queue manager. The easiest way of closing the channels is to set
the MCAUSER value to a non-existing user. The following MQSC script performs these
changes on a queue manager:
ALTER
ALTER
ALTER
ALTER
ALTER
ALTER
ALTER
ALTER
ALTER
CHL(SYSTEM.AUTO.RECEIVER) CHLTYPE(RCVR) MCAUSER(NOUSER)
CHL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.CLUSRCVR) CHLTYPE(CLUSRCVR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.CLUSSDR) CHLTYPE(CLUSSDR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.RECEIVER) CHLTYPE(RCVR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.REQUESTER) CHLTYPE(RQSTR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.SENDER) CHLTYPE(SDR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.SERVER) CHLTYPE(SVR) MCAUSER(NOUSER)
CHL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MCAUSER(NOUSER)
Channels created must set the MCAUSER value to to a valid user (not an empty value)
to allow for applications or queue managers to connect. This is defined as an open
channel.
6 (7)
Project: RSD General
Document: Integration Platform Test
Version: 1.0
Date: 2008-04-18
All open channels must have SSL configured to allow the queue manager to
authenticate the connecting application or queue manager. The SSLPEER attribut on the
channel should be set to validate that only the expcted parties are allowed to connect
(e.g. client applications can only connect on their own channel, a test queue manager
can not connect to the production environment).
For authentication purposes only, NULL_SHA1 is the best available cipher suite. For
encryption, AES_256 is recommended.
Applications connecting as client should be given individual SVRCONN channels with
the SSLPEER attribute set to only allow that application to connect. The MCAUSER
value must be set to the appropriate user. The UserID provided on the messages should
not be trusted and must be overwritten by the user provided on the channel.
Since MQ Explorer 5.3 does not support connecting remotely using SSL other
administrative tools must be used, such as MQMon.
SSL
When setting up a new key store on a queue manager, WMQ adds a set of default,
trusted third party certificates to the key store. These should be removed to disallow
applications with certificates signed by any third party to access the queue manager.
File access
The directories containing MQ files (e.g. /var/mqm, c:\program files\IBM\WebSphere
MQ) contains files crucial for MQ security (e.g. the certificate key store) and must be
protected from unauthorized access. The directories must only be accessiable for
administrators and the user running MQ.
7 (7)