Channel security

 

+

Search Tips   |   Advanced Search

Overview

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):

  1. 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.

  2. 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.

  3. 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, 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 Intercommunication for more information about channel exits.

 

Protecting channels with SSL

The 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 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 authentication information objects. Each authentication information 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 dspmqfls commands to support the authentication information object. It also describes the amqmcert command for managing certificates on Windows systems, and the IKEYCMD command for managing certificates on UNIX systems.

 

 

 

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.