+

Search Tips   |   Advanced Search

WebSphere MQ server: Connection and authentication

Each WebSphere MQ server definition includes the connection properties and authentication settings that service integration uses to connect to the associated WebSphere MQ queue manager or queue-sharing group, either for resource discovery or for messaging.


Connection

  • Service integration connects to the WebSphere MQ network in the following situations:

    • When, as part of the process of creating a WebSphere MQ server using the console, the automatic resource discovery process runs to capture resource information direct from WebSphere MQ. The wsadmin commands do not support automatic discovery of resources.

    • When the WebSphere MQ server is used to pass messages between service integration and WebSphere MQ.

    The connection access path is determined by the host, port, transport chain and WebSphere MQ connection channel specified when creating the WebSphere MQ server definition. You get this information from the WebSphere MQ system administrator. The connection access path is also affected by the connection mode specified:

    • We can use client transport mode to establish a TCP/IP network connection between service integration and WebSphere MQ.

    • If WAS and WebSphere MQ are co-located on the same system (or, for z/OS systems, on the same partition of the same system) it is more efficient to use bindings transport mode to connect between service integration and WebSphere MQ.

    For more information about the mechanisms used to connect to WebSphere MQ for z/OS, see the z/OS System Setup Guide in the WebSphere MQ information center.


    Authentication

    The WebSphere MQ system administrator will probably want service integration to authenticate with WebSphere MQ whenever it connects. This happens whenever message data needs to be exchanged with a queue point or a mediation point assigned to a WebSphere MQ server bus member, and when the automated resource discovery process runs while you are configuring a WebSphere MQ server using the console.

    The WebSphere MQ system administrator might also want to set up two different user accounts on the WebSphere MQ system: one with only the privileges needed for resource discovery, and one with only the privileges needed for messaging. The WebSphere MQ server definition supports this requirement by allowing you to configure the MQ server with two authentication aliases, corresponding to these two accounts.

    Authentication aliases are restricted to a maximum 12 characters in length, because the user ID that WebSphere MQ uses for checking the identity of new connections also has this restriction. If authentication aliases exceed 12 characters in length, they are truncated.

    If we are using Resource Access Control Facility (RACF ) as the security manager on the WebSphere MQ for z/OS system, and using bindings transport mode, specify in uppercase characters the user names and passwords for authentication aliases. If we are using RACF and client transport mode, we can specify the user names and passwords in either upper or lowercase characters.

    Where an authentication alias exists, the user name and password it contains are examined by WebSphere MQ by using a WebSphere MQ channel security exit. WebSphere MQ for z/OS provides a sample security exit CSQ4BCX3, which demonstrates how we can authenticate based on this information.

    When messages are sent to WebSphere MQ for resource discovery, the MQPMO_SET_IDENTITY_CONTEXT option is used. The credentials used to establish a messaging connection must have authority to assert this.

    The connection mode you use for connecting to WebSphere MQ affects which credentials are used:

    • For a client transport mode connection, the user ID and password from the authentication alias are used by WebSphere MQ. If an authentication alias is not specified in the WebSphere MQ server definition, WebSphere MQ is presented with an empty string for both the user ID and password.

    • For a bindings transport mode connection, the credentials associated with the application server processes are used for authentication by WebSphere MQ. Therefore service integration instructs the application server processes to switch credentials and use the user ID and password that exist in the relevant WebSphere MQ server authentication alias. This in turn requires that the application server processes start with sufficient privileges to connect and perform the switch. If an authentication alias is not specified in the WebSphere MQ server definition, a switch of credentials is not attempted and the original credentials of the application server process are used. For resource discovery the credentials are those of a servant address space in a single server configuration, and those of the deployment manager address space in a network-deployment configuration. For messaging work the credentials are those of the control region adjunct address space.


    Overriding the connection and authentication settings

    When we add the WebSphere MQ server definition to a service integration bus to make it a bus member, we can override the server settings and authentication alias used for messaging, with the connection settings and authentication alias used by the bus. We can use this option to create a bus-specific instance of that server and is useful in a multiple bus configuration. Typically you would do this to differentiate connections from different buses and, potentially, to apply different security settings.


    Related tasks

  • Create a WebSphere MQ server definition

  • createSIBWMQServer command