System Administration Guide

Channel security

Message channel agents (MCAs) are WebSphere MQ applications and need access to various WebSphere MQ resources.

The user ID associated with a sending channel needs access to the queue manager, the transmission queue, the dead-letter queue, and any resources required by channel exits.
The user ID associated with the receiving channel needs to open the target queues to put messages onto them. This involves the MQI, so access control checks might need to be made. You can specify whether these checks are made against the user ID associated with the MCA (as described below), or the user ID associated with the message (from the MQMD context field).
The PUTAUT parameter of the channel definition specifies which user ID is used for these checks.
- If you use the user ID of the MCA, this user ID will already be defined on the local system.
- If you use the user ID associated with the message, it is likely that this is a user ID from a remote system. This remote system user ID must be recognized by the target system and have the authority to connect to the queue manager, make inquiries, set attributes, and set context options (+connect, +inq, +set, and +setall). It must also have authority to put messages and set context information (+put and +setall) for the destination and dead-letter queues.

The user ID associated with the MCA depends on the type of MCA.

Caller MCA

These are MCAs that initiate a channel. They can be started as individual processes, as threads of the channel initiator, or as threads of a process pool. The user ID used is that associated with the parent process (the channel initiator), or the process causing the MCA to be started.

Responder MCA

These are MCAs that are started as a result of a request by a caller MCA. They can be started as individual processes, as threads of the listener, or as threads of a process pool. The user ID can be any one of the following (in this order of preference):

On APPC, the caller MCA can indicate the user ID to be used for the responder MCA. This is called the network user ID and applies only to channels started as individual processes. This is set using the USERID parameter of the channel definition.
If the USERID parameter is not used, the channel definition of the responder MCA can specify the user ID that the MCA is to use. This is set using the MCAUSER parameter of the channel definition.
If the user ID has not been set by either of the methods above, the user ID of the process that starts the MCA or the user ID of the parent process (the listener) is used.

Protecting the definitions associated with channels

WebSphere MQ channels, channel initiators, and listeners are not WebSphere MQ objects; access to them is not controlled by the OAM. WebSphere MQ does not allow users or applications to manipulate these objects, unless their user ID is a member of the mqm group. If you have an application that issues the PCF commands listed below, the user ID specified in the message descriptor of the PCF message must be a member of the mqm group on the target queue manager.

ChangeChannel
CopyChannel
CreateChannel
DeleteChannel
PingChannel
ResetChannel
StartChannel
StartChannelInitiator
StartChannelListener
StopChannel
ResolveChannel

A user ID must also be a member of the mqm group on the target machine to issue the equivalent MQSC commands through the Escape PCF command or using runmqsc in indirect mode.

Transmission queues

Queue managers automatically put remote messages on a transmission queue; no special authority is required for this. However, putting a message directly on a transmission queue requires special authorization; see Table 10.

Channel exits

You can use channel exits for added security. A security exit forms a secure connection between two security exit programs, where one program is for the sending message channel agent (MCA), and one is for the receiving MCA.

On WebSphere MQ for Windows, there is a security exit for both the WebSphere MQ client and the WebSphere MQ server. This is a channel exit program that provides authentication for WebSphere MQ channels by using the Security Services Programming Interface (SSPI). The supplied channel exit programs provide either one-way or two-way (mutual) authentication of a partner system when a session is being established. For a particular channel, each exit program has an associated principal. A connection between two exit programs is an association between the two principals.

The exit source code file is called amqsspin.c, and is stored in the C:\Program files\IBM\WebSphere MQ\tools\c\samples directory. If you modify the source code, you must recompile the modified source. The source code does not include any provision for tracing or error handling. If you choose to modify and use the source code, add your own tracing and error-handling routines. You compile and link the file in the same way as any other channel exit, except that SSPI headers need to be accessed at compile time, and SSPI libraries need to be accessed at link time. See WebSphere MQ for Windows, V5.3 Quick Beginnings for more information.

See WebSphere MQ Intercommunication for more information about channel exits.

Protecting channels with SSL

The Secure Sockets Layer (SSL) protocol provides out of the box channel security, with protection against eavesdropping, tampering, and impersonation. WebSphere MQ support for SSL enables you to specify, on the channel definition, that a particular channel uses SSL security. You can also specify details of the kind of security you want, such as the encryption algorithm you want to use.

SSL support in WebSphere MQ uses the queue manager authentication information object, authinfo, and various MQSC commands and queue manager and channel parameters that define the SSL support required in detail.

The following MQSC commands support SSL:

ALTER AUTHINFO: Modifies the attributes of an authentication information object.
DEFINE AUTHINFO: Creates a new authentication information object.
DELETE AUTHINFO: Deletes an authentication information object.
DISPLAY AUTHINFO: Displays the attributes for a specific authentication information object.

The following queue manager parameters support SSL:

SSLCRLNL

Allows access to a certificate revocation list. The SSLCRLNL attribute specifies a namelist. The namelist contains zero or more AUTHINFO objects. Each AUTHINFO object gives access to an LDAP server.

SSLKEYR

Associates a key repository with a queue manager. The SSLKEYR attribute depends on the platform you are using:

On UNIX systems, the key database is held in a GSKit key database. (The IBM Global Security Kit (GSKit) enables you to use SSL security on UNIX systems.)
On Windows systems, the key database is held in a Microsoft Certificate store file.

SSLCRYP

On UNIX systems only, sets the SSLCryptoHardware queue manager attribute. This attribute is the name of the parameter string that you can use to configure the cryptographic hardware you have on your system.

The following channel parameters support SSL:

SSLCAUTH: Defines whether WebSphere MQ requires and validates a certificate from the SSL client.
SSLCIPH: Specifies the encryption strength and function (CipherSpec), for example NULL_MD5 or RC4_MD5_US. The CipherSpec must match at both ends of channel.
SSLPEER: Specifies the distinguished name (unique identifier) of allowed partners.

This book describes changes to the setmqaut, dspmqaut, dmpmqaut, rcrmqobj, rcdmqimg, and dspmqflscommands to support the SSL authentication information object, authinfo. It also describes the amqmcert command for managing certificates. See the following sections:

For an overview of channel security using SSL, see WebSphere MQ Security.

For details of the new commands and the new channel and queue manager attributes, see the WebSphere MQ Script (MQSC) Command Reference.

For details of PCF commands associated with SSL, see WebSphere MQ Programmable Command Formats and Administration Interface.