Skip to main content

skip to main content

developerWorks  >  WebSphere | Tivoli  >

End-to-end security and message protection in a WebSphere MQ client/server environment

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Intermediate

Abhishek Jha (abhishek_jha@in.ibm.com), IBM Tivoli Access Manager for Business Integration team, IBM
Mehak Mahajan (mehak.mahajan@in.ibm.com), IBM Tivoli Access Manager for Business Integration team, IBM

18 Apr 2007

This article shows you how to use IBM Tivoli Access Manager for Business Integration, which is provided as part of WebSphere MQ V6 Enterprise Security Edition, to secure WebSphere MQ clients and provide end-to-end message security. It also describes how Tivoli Access Manager supplements WebSphere MQ security, and the steps required to configure client security.

Introduction

Customers are sometimes reluctant to deploy IBM® WebSphere® MQ (hereafter called MQ) in a client/server configuration because of security concerns. The best way to provide this security is to build on existing MQ security features instead of trying to replace them wholesale with another product. IBM Tivoli® Access Manager for Business Integration (hereafter called Tivoli Access Manager) reinforces MQ security non-intrusively, seamlessly integrating with the existing setup and closely incorporating the existing MQ security infrastructure, including MQ SSL, Channel Security Exits, and Object Authority Manager. Tivoli Access Manager provides client authentication (by closely integrating with MQ SSL), authorization, data protection, and centralized administration of these policies across the enterprise via the Web-based GUI (Web Portal Manager) and the command-line utility pdadmin.


Figure 1. Tivoli Access Manager for Business Integration protecting MQ client-server architecture
Figure 1. Tivoli Access Manager for Business Integration protecting MQ client-server architecture

Tivoli Access Manager secures MQ resources by intercepting the calls to the MQ API. The MQ Client Interceptor configured on the MQ client and the MQ Server Interceptor configured on the MQ server intercept the Message Queue Interface (MQI) calls. The intercepted calls are then authenticated and authorized at the application level by using the centralized Tivoli Access Manager Policy Server and user registry (LDAP user registry).

How Tivoli Access Manager supplements MQ security

Tivoli Access Manager:

  • Provides authentication, authorization, and data protection on the client side by intercepting the MQ client API calls.
  • Performs authentication via a two-step process: Tivoli Access Manager represents each operating system user with two identities: a Public Key Infrastructure identity (the Distinguished Name in an X.509 certificate) and a Tivoli Access Manager identity. Tivoli Access Manager performs authentication by correlating these identities.
  • Provides for centralized access control as well as data protection policies, as opposed to the Object Authority Manager, which defines access control policies on a per-node basis.
  • Closely integrates with MQ SSL to prevent MQ clients that do not have a valid Tivoli Access Manager ID from connecting to protected MQ servers via a server-side security exit.
  • Detects and removes rogue or unauthorized messages before they are processed by a receiving application.
  • Checks and audits the MQI operations performed by the MQ client at the server end for proper authorizations.

Using Tivoli Access Manager for MQ client security

Tivoli Access Manager closely integrates various MQ security features to provide security for MQ clients at various levels. It relies on MQ SSL for client authentication, and builds on this infrastructure to provide authorization decisions at the server end to secure clients that do not come under the purview of Tivoli Access Manager (such as MQ client calls that are not intercepted by Tivoli Access Manager). This authorization at the server end is provided via a server-side security exit provided by Tivoli Access Manager.

Tivoli Access Manager gives administrators the flexibility of choosing the security level. For MQ clients, administrators can choose:

  1. Authentication, authorization, and data protection on the client by configuring only the Client Interceptor.
  2. Authentication and authorization on the server without data protection, by configuring only the server-side security exit.
  3. A combination of the two for client authentication, authorization on both client and server, and data protection on the client.

The following table lists the different MQ and Tivoli Access Manager configurations and the resultant level of security:


Table 1. Securing MQ: Tivoli Access Manager scenarios
Server InterceptorClient InterceptorMQ SSLServer-side security exitLevel of security for MQ clientComment
YesNoNoNoNoneRogue clients [1] Can access the MQ resources.
YesYesNoNoAuthentication, authorization, data protectionAuthentication of Access Manager ID[2] No security from rogue clients. Authorization also based on Access Manager ID.
YesNoYesNoAuthenticationAuthentication done by MQ SSL[3]
YesNoYesYes-Authentication, authorization at serverAuthentication done by MQ SSL and authorization based on Access Manager ID
YesYesYesNoAuthentication, authorization, data protectionAuthentication done by both MQ SSL and Access Manager, authorization, data protection[4] by Tivoli Access Manager
YesYesYesYesAuthentication, authorization, data protectionMost comprehensive level of security. Rogue clients cannot connect to queue manager. Authentication done by both MQ SSL and Access Manager. Authorization done by Access Manager. Data protection applied at client by Tivoli Access Manager

Table notes

[1] Rogue clients are MQ clients that do no come under the purview of Tivoli Access Manager Client Interceptor.

[2] Authentication by Tivoli Access Manager is a two-step process in which the OS-ID of the user is mapped to a PKI-ID (DN of the user's certificate), which in turn maps to an access manager ID that is stored in the user registry.

[3] Authentication by MQ SSL takes place if SSLCAUTH in the SVRCONN is set to required, based on mutual exchange of certificates by the authenticating parties and comparison of the DN presented in the certificates with that given in the SSLPEER of SVRCONN.

[4] Data protection based on the quality of protection specified in the Protected Object Policy. It means either digitally signing the message (integrity) or digitally signing and encrypting the message (privacy). Protection of the message originating at the client is done by the Client Interceptor.

Securing WebSphere MQ client

This section shows you how to configure Tivoli Access Manager to secure an existing MQ client/server scenario. Scenarios depict the different levels of security as described in Table 1 above. In each scenario, the security provided by Tivoli Access Manager will be either increased or modified to provide specific security features and provide the most comprehensive security level as described in the last row of Table 1.

Here are the components needed in the setup:


Figure 2. Components in a Tivoli Access Manager for Business Integration setup
Figure 2. Components in a Tivoli Access Manager for Business Integration setup

For the sake of clarity, each major component is installed on a separate machine -- Tivoli Access Manager Policy Server, Web Portal Manager, MQ server, and MQ client. At deployment time, one or more of these can be installed on the same machine.

In this setup, Tivoli Access Manager V5.1 Fix Pack 5 has been deployed. For details of the versions of the other installed products, see the Tivoli Access Manager V5.1 Fix Pack 5 ReadMe file. For all of the scenarios, we will first enlist the common setup required for MQ and for Tivoli Access Manager.

Common MQ setup

The MQ server is a Queue Manager, QM1, on a Solaris V8.0 machine (Hostname solaris-server and IP 9.182.195.12). The client is set up on an AIX V5.3 machine (Hostname aix-client and IP 9.182.195.20). The client/server channel is called SVR_CLNT, and the SSL setup on this channel will be enabled/disabled as demanded by the scenario. A local queue called Q_LOCAL is defined within QM1. The client user on the AIX 5.3 machine is called as client.

Here is an example of how to set up a client/server channel:

solaris-server# runmqsc QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2005.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager QM1.

define channel(SVR_CLNT) chltype(SVRCONN) sslciph(TRIPLE_DES_SHA_US)  
			sslcauth(optional) mcauser('client')
	1 : define channel(SVR_CLNT) chltype(SVRCONN) sslciph(TRIPLE_DES_SHA_US)  
			sslcauth(optional) mcauser('client')
AMQ8014: WebSphere MQ channel created.
define channel(SVR_CLNT) chltype(CLNTCONN) sslciph(TRIPLE_DES_SHA_US)  
			conname('9.182.195.12(1414)') qmname(QM1)
	2 : define channel(SVR_CLNT) chltype(CLNTCONN) sslciph(TRIPLE_DES_SHA_US)  
			conname('9.182.195.12(1414)') qmname(QM1)
AMQ8014: WebSphere MQ channel created.

To complete the client/server setup, transfer the Client Channel Table of Queue Manager QM1 (/var/mqm/qmgr/QM1/@ipcc/AMQCLCHL.TAB) to the client machine aix-client (say the file has been transferred to /tmp). Log in as user client and set the following environment variables whenever a message has to be PUT/GET using this client/server channel. For the SSL purposes, the certificates of the user client is stored in the keystore /tmp/pkiuser.kdb and has the DN CN=pkiuser,O=ibm,C=IN.

aix-client# export MQCHLTAB=AMQCLCHL.TAB
aix-client# export MQCHLLIB=/tmp
aix-client# export MQSSLKEYR=/tmp/pkiuser

Tivoli Access Manager setup

The Access Manager Policy Server and the IBM LDAP Server for these scenarios has been configured on solaris-server. For all purposes the Access Manager Policy Server and/or the IBM LDAP Server can be configured on a separate machine and the Access Manager Runtime on the solaris-server and aix-client will need to be configured to this Policy Server.

For details of setting up the Policy Server, see Tivoli Access Manager V6 Base Installation Guide.

.

Server (Solaris V8.0)

  • Configure the Server Interceptor to the desired domain. In this case, use the default domain and the default administrative ID sec_master: 
    solaris-server# pdmqsvrcfg -action config -admin_id sec_master -admin_pwd tivoli

  • Configure the API exit for the Queue Manager QM1 by adding the stanza below to the file /var/mqm/qmgrs/QM1/qm.ini: 
    ApiExitLocal:
Name=ambi_axe
Function=ambi_axe_init
Module=/var/mqm/exits/ambi_axe
Sequence=1

    On platforms with 32-bit and 64-bit implementations of the MQ libraries MQ V6 on AIX, Solaris, and HP-UX), the line Module=/var/mqm/exits/ambi_axe should be changed to Module=ambi_axe for both 32 and 64-bit applications.

  • Add the queue manager QM1 to the protected object space: 
    solaris-server# pdmqsvrcfg -action add -qm QM1 -admin_id sec_master -admin_pwd tivoli

Client (AIX V5.3)

  1. Configure the Client Interceptor: 
    solaris-server# pdmqclientcfg -action config -admin_id sec_master -admin_pwd tivoli

    The Interceptor is now configured and enabled. For the various scenarios listed below, the Client interceptor will be either disabled or enabled using one of the following commands:

    solaris-server# pdmqclientcfg -action disable
solaris-server# pdmqclientcfg -action enable

  2. Map the operating system identity client to the PKI Identity CN=pkiuser,O=ibm,C=IN. The PKI identity is the DN contained in the certificate used by the user client for the SSL handshake. To achieve the mapping, edit the file /opt/pdmq/etc/map.conf on aix-client to add the following line: 
    client,/tmp/pkiuser,ibmwebspheremqclient

    where client is the operating system identity:

    • /tmp/pkiuser -- Absolute path of user client's kdb file without the .kdb extension
    • ibmwebspheremqclient -- Label of user client's certificate in the keystore /tmp/pkiuser.kdb
  3. Update the Tivoli Access Manager daemons cache by executing aix-client# pdmqd -update.
  4. Map the PKI Identity CN=pkiuser,O=ibm,C=IN to the Tivoli Access Manager User identity amuser. Create a file called /tmp/user.ldif containing the following lines: 
            
dn: principalName=amuser,cn=Users,secAuthority=Default
secCertDN: cn=pkiuser,o=ibm,c=in

  5. Run the following command with appropriate values for the -D (LDAP Admin ID), -w (LDAP Admin password), -h (LDAP Server), and -p (LDAP Server Port) options: 
    aix-client# ldapmodify -D cn=root -w tivoli -h solaris-server -p 389 -f  /tmp/user.ldif

  6. Use the same kdb for the Tivoli Access Manager client (the access manager user amuser in this case) and the MQ client client. In this case both have the DN 
    CN=pkiuser,O=ibm,C=IN

    .

Policy server tasks

For the purpose of this article, all Policy Server tasks will be handled using the command-line utility pdadmin. An alternative is the Web Portal Manager, which provides a Web-based GUI for these tasks. The Web Portal Manager provides a unified view of all Queue Managers in the domain, irrespective of the machines they are defined on, which simplifies policy administration.

Create and attach the acl (acl_QM1) and pop (pop_QM1) to the Queue Manager object:

solaris-server# pdadmin -a sec_master -p tivoli
pdadmin sec_master> acl create acl_QM1
pdadmin sec_master> acl attach /PDMQ/Queue/QM1 acl_QM1
pdadmin sec_master> pop create pop_QM1
pdadmin sec_master> pop attach /PDMQ/Queue/QM1 pop_QM1
pdadmin sec_master> object show /PDMQ/Queue/QM1
    Name: /PDMQ/Queue/QM1
        Description: Queue-Manager
        Type: 13 (Unknown)
        Is Policy Attachable: Yes
        Extended Attributes:
        Attached ACL: acl_QM1
        Attached POP: pop_QM1
        Attached AuthzRule:

        Effective Extended Attributes:
        Effective ACL: acl_QM1
        Effective POP: pop_QM1
        Effective AuthzRule:

The permissions for the access manager user amuser in the ACL and Quality of Protection (qop) and audit-level in the POP, vary depending on the scenario. Follow the steps below to change the permissions in an ACL:

pdadmin sec_master> acl modify acl_QM1 set user amuser T[PDMQ]EDR
pdadmin sec_master> acl show acl_QM1
  	    ACL Name: acl_QM1
    Description:
    Entries:
    User sec_master TcmdbsvaBRl
    User amuser T[PDMQ]EDR

In the above command, E stands for En-queue, D for De-queue, and R for Remote-Connect. Set these permissions in the ACLs as desired. The permission R lets clients connect to the protected Queue Managers remotely. The following steps show how to to change the qop and audit-level of a POP:

pdadmin sec_master> pop modify pop_QM1 set qop none
pdadmin sec_master> pop modify pop_QM1 set audit-level all
pdadmin sec_master> pop show pop_QM1
    Protected object policy:  pop_QM1
    Description:
    Warning:  No
    Audit level:  all
    Quality of protection:  none
    Time of day access:  sun, mon, tue, wed, thu, fri, sat, :anytime:local
    IP Endpoint Authentication Method Policy
        Auth Level: 0          Network: Any Other Network

In the above command, you can set qop to none, integrity, or privacy and set audit-level to permit, deny, all, error, or admin depending on the nature of audit records to be generated for operations that access protected MQ resources. For details, see the Tivoli Access Manager Admin guide.

Scenarios

In all the following scenarios, before you PUT/GET the message, always log in as user client on aix-client and set the environment variables as described above in the section Common MQ setup.

Scenario 1

Both Server and Client Interceptor are enabled, and SVR_CLNT channel is not MQ SSL-enabled.

  1. Enable both Server and Client Interceptor as shown.
  2. The channel definition devoid of SSL parameters is as follows: 
    define channel(SVR_CLNT) chltype(SVRCONN) mcauser('client')
define channel(SVR_CLNT) chltype(CLNTCONN) conname('9.182.195.12(1414)') qmname(QM1)

  3. Set the ACL permissions to allow En-queue (E). The client will not be given permissions to De-queue (D) the message. Any attempt to GET the message will fail with MQRC 2035, Authorization Error.
  4. Set the qop in the POP to the appropriate level (none, integrity, or privacy)
  5. Log in as client user on the aix-client and PUT and GET the message from the queues: 
    aix-client# /usr/mqm/samp/bin/amqsputc Q1 QM1
Sample AMQSPUT0 start
target queue is Q1
test message
Sample AMQSPUT0 end

aix-client# /usr/mqm/samp/bin/amqsgetc Q1 QM1
Sample AMQSGET0 start
MQOPEN ended with reason code 2035
unable to open queue for input
Sample AMQSGET0 end

In this scenario, if a rogue client (MQ client machine with no Client Interceptor) tries to access the resources by virtue of knowing the listener's port, the queue name, and queue manager name, it will be granted access. See the Pointers section.

Scenario 2

Both Server and Client Interceptor are enabled, SVR_CLNT channel is MQ SSL-enabled, but Tivoli Access Manager server side security exit is not in place.

  1. Enable both Server and Client Interceptor as shown above.
  2. Here is the channel definition with MQ SSL in place: 
    define channel(SVR_CLNT) chltype(SVRCONN) sslciph(TRIPLE_DES_SHA_US) 
	sslpeer('CN=pkiuser,O=ibm,C=IN') +
	sslcauth(required) mcauser('client')
define channel(SVR_CLNT) chltype(CLNTCONN) sslciph(TRIPLE_DES_SHA_US) 
	sslpeer('CN=qm1,O=ibm,C=IN') +
	conname('9.182.195.12(1414)') qmname(QM1)

  3. Set the MQ environment variables required to enable an MQ client to connect to the server across an MQ SSL-enabled channel.
  4. Set the ACL permissions to allow En-queue (E) and De-queue (D).
  5. Set the qop in the POP to the appropriate level (none, integrity, or privacy)
  6. Log in as client user on the aix-client and PUT and GET the message from the queues.

In this scenario, a rogue client (MQ client machine with no Client Interceptor) will be allowed to access the MQ resources if it manages a successful MQ SSL handshake. Access is allowed because, with no server-side security exit in place, authorization decisions are made only on the client by Tivoli Access Manager. Of course, here too, the rogue client must know the listener's port, the queue name, and the queue manager's name. For more information, see Tips.

Scenario 3

Server Interceptor is enabled but Client Interceptor is not configured, SVR_CLNT channel is MQ SSL-enabled, and Tivoli Access Manager server side security exit is in place. This scenario might arise when data protection is not the prime focus. In this case, MQ SSL will be used to authenticate the client, and the authorization decisions will be initiated by the server side security exit.

  1. The setup is similar to Scenario 2, except that the Client Interceptor is not configured, which implies that there is no Tivoli Access Manager component on the client.
  2. Here is the server side channel definition with the server side security exit: 
    define channel(SVR_CLNT) chltype(SVRCONN) sslciph(TRIPLE_DES_SHA_US) 
	sslpeer('CN=pkiuser,O=ibm,C=IN') +
	sslcauth(required) mcauser('client') scyexit('/var/mqm/exits/ambi_axe(securityExit)')

  3. Set the ACL permissions to allow En-queue (E) and De-queue(D). Additionally, with the server side security exits in place, permission to remote-connect (R) must be specified in the ACL. Qop can be specified only as none, since there can be no data protection. Specifying an alternative qop (integrity or privacy) will lead to errors when Tivoli Access Manager protected MQ client applications try to GET messages
  4. Log in as client user on the aix-client and PUT and GET the message from the queues: 
    aix-client# /usr/mqm/samp/bin/amqsputc Q1 QM1
Sample AMQSPUT0 start
target queue is Q1
test message
Sample AMQSPUT0 end

aix-client# /usr/mqm/samp/bin/amqsgetc Q1 QM1
Sample AMQSGET0 start
message [test message]
no more messages
Sample AMQSGET0 end

Scenario 4

Both Server and Client Interceptor are enabled, the SVR_CLNT channel is MQ SSL-enabled, and the Tivoli Access Manager server side security exit is in place. This is the most comprehensive security solution offered by Tivoli Access Manager to protect MQ client applications. The set-up is similar to Scenario 2.

  1. Modify the server side channel definition to include the server side security exit.
  2. Set the ACL permissions to allow En-queue (E), De-queue(D), and Remote-connect (R).
  3. Set the qop in the POP to the appropriate level (none, integrity, or privacy).
  4. Log in as client user on the aix-client and PUT and GET the message from the queues.
aix-client# /usr/mqm/samp/bin/amqsputc Q1 QM1
Sample AMQSPUT0 start
target queue is Q1
test message
Sample AMQSPUT0 end

aix-client# /usr/mqm/samp/bin/amqsgetc Q1 QM1
Sample AMQSGET0 start
message [test message]
no more messages
Sample AMQSGET0 end

Tips

  1. In Scenarios 1 and 2, if a Tivoli Access Manager protected client application tries to GET a message PUT there by a rogue client, and the qop specified is other than none, an error will be flagged, thus protecting a valid application from getting a phony message. This is done because, when a client application protected by Tivoli Access Manager tries to GET a message that it is expecting to be protected via qop integrity or privacy, it verifies the signature (in case of privacy and integrity) and decrypts the message (only in case of privacy). If it is unable to do so, the message is sent to the error queue and the application is notified of an error. To simulate a rogue client, simply disable the Client Interceptor, and change the qop specified on the Queue Q1 to integrity. Now log in as user client on aix-client, set the environment variables as usual, and PUT a message on Q1 on QM1. The PUT will succeed:

    aix-client# /usr/mqm/samp/bin/amqsputc Q1 QM1
Sample AMQSPUT0 start
target queue is Q1
test message
Sample AMQSPUT0 end

  2. Enable the Client Interceptor, and try to GET the message from Q1 on QM1. The GET will fail with 2109, because of qop integrity, which requires that the message on the queue be signed by the sender when it PUTs the message. In case of a rogue client, the signing doesn't happen because there is no Tivoli Access Manager Client Interceptor enabled to sign it. 
    Sample AMQSGET0 start
MQGET ended with reason code 2109
unable to open queue for input
Sample AMQSGET0 end

  3. In scenarios 1 and 2, Tivoli Access Manager will not prevent a rogue client from getting a message. If the QoP is privacy, however, the message they GET will be encrypted so it will only be a denial-of-service, rather than an information leak.

Conclusion

You can use Tivoli Access Manager to build on and integrate with existing WebSphere MQ security mechanisms to provide authentication, authorization, and end-to-end data protection for your enterprise messaging environment. In addition, Tivoli Access Manager facilitates the management of security policies by providing centralized administration. Tivoli Access Manager is thus an all-in-one solution for securing your WebSphere MQ enterprise messaging environment.



Resources



About the authors

Abhishek K Jha is a Functional Verification Test Engineer on the IBM Tivoli Access Manager for Business Integration team at the IBM India Software Lab in Pune. You can contact Abhishek at abhishek_jha@in.ibm.com.


Mehak Mahajan is a Functional Verification Test Engineer on the IBM Tivoli Access Manager for Business Integration team at the IBM India Software Lab in Pune. You can contact Mehak at mehak.mahajan@in.ibm.com.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful		Extremely
useful
 


Back to top