Contents


Comparing BlockIP2 with Channel Authentication Records for WebSphere MQ Security

Comments

BlockIP2 is a well-known independent software vendor (ISV) security exit for IBM® WebSphere® MQ that is widely used. WebSphere MQ V7.1 and later provide the ability to implement similar security functions to those commonly implemented in security exits with the use of channel authentication records, also known as the CHLAUTH command.

This article provides an overview and comparison of the most commonly used features in BlockIP2 and CHLAUTH. The article's main objective is to help those who are familiar with security to become acquainted with how channel authentication records can replace BlockIP2 functionalities.

The version of BlockIP2 used in this article is version 2.93, but it should apply equally to other versions. The version of WebSphere MQ used in this article is V7.1.0.6, but it should apply equally to later versions unless explicitly noted.

BlockIP2 overview

WebSphere MQ provides a feature called a security exit that allows ISVs to implement functions associated with security. BlockIP2 is a security exit that can be used to provide security by enforcing authentication on channels.

The BlockIP2 exit can be used to perform the following functions:

  • IP address mapping
  • IP address blocking
  • Certificate DN mapping
  • Certificate DN blocking
  • Client user ID mapping
  • Client user ID blocking

Channel authentication records overview

Channel authentication records can be used to provide precise control over authentication and authorization of remote connections connecting to the queue manager at a channel level or listener level. Channel authentication records perform the same functions listed for BlockIP2, as well as two additional functions:

  • Remote queue manager name mapping
  • Remote queue manager name blocking

In WebSphere MQ V7.1 and later, CHLAUTH is enabled by default when you create a queue manager. If you have a queue manager at an earlier release than V7.1, installing the new version will not enable CHLAUTH automatically. The WebSphere MQ administrator has to enable CHLAUTH manually.

Migrating from BlockIP2 to CHLAUTH

This scenario is a sample implementation that shows how you can migrate from using BlockIP2 to using CHLAUTH. The BlockIP2 configuration file is shown below.

Figure 1. Sample BlockIP2 Configuration File

#######################################################################

# 1.Block mqm users
BlockMqmUsers=Y;
# 2. Specific channel limitations
MAXCHL=SYSTEM.DEF.SVRCONN;25;   
MAXCHL=SYSTEM.ADMIN.SVRCONN;25;
MAXCHL=SYSTEM.AUTO.SVRCONN;25;
# 3. Block user id:alis
BlockUsers=alis;
# 4. Allow clientuser1 when coming from 172.20.10.31, using the MCAUSER settings
CON=172.20.10.31;;clientuser1;
# 5. Allow tester when coming from 10.*, and set MCAUSER to clientuser2
CON=10.*;tester;MCA=clientuser2;
# 6.Allow connections from DN Organization's name='MQORG'
and map them to MCA user 'mqusers'
SSL=O=MQORG;MCA=mqusers;
# 7. Block connection attempts that don't match any of the other rules.
CON=*;*;BLOCK;

#######################################################################

To demonstrate how you convert from a BlockIP2 configuration file such as above to CHLAUTH commands, the following sections describe each component in the file and how CHLAUTH can do the same thing.

IP address mapping

Both BlockIP2 and CHLAUTH can be used to set an MCAUSER for any channel connecting from a specific IP address. If you are using BlockIP2, the CON property can be used to specify the IP address and MCAUSER value that you want to set.

The following property allows a connection from IP address 10.7.0.139 and maps it to MCAUSER mqtestusers:

CON=10.7.0.139;;MCA=mqtestusers;

You can use a channel authentication record to set the MCAUSER attribute of a channel, according to the IP address from which the connection is received.

The following command allows a connection from IP address 10.7.0.139 and maps it to MCAUSER mqtestusers:

SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('10.7.0.139') USERSRC(MAP) MCAUSER('mqtestusers')

IP address blocking

Both BlockIP2 and CHLAUTH can be used to block the connection of a channel connecting from a specific IP address. If you are using BlockIP2, you can specify IP addresses to be blocked in the configuration file by using the CON property.

The following property blocks IP addresses 10.21.* from connecting to the queue manager:

CON=10.21*;;BLOCK;

An incoming connection must name a valid MQ channel definition containing the BlockIP2 security exit, or the BlockIP2 exit won't get invoked. Global IP rules can be used in CHLAUTH to block connections that are not MQ channel connections.

Using CHLAUTH we can set a rule to disallow specific IP addresses from connecting to the queue manager. There are two types of rules that we can set for IP address blocking.

Global IP rules allow you to block the connection at the listener itself without knowing the channel name. In fact, the connection may not even be an MQ channel.

The following command blocks the IP addresses 10.21.* from connecting to the queue manager without knowing the channel name:

SET CHLAUTH('*') TYPE(BLOCKADDR) ADDRLIST('10.21.*')

Per-channel rules allow you to set a rule to block IP addresses from using a specific channel.

The following command blocks the IP addresses 10.21.* from connecting to server connection channel SYSTEM.DEF.SVRCONN:

SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('10.21.*') USERSRC(NOACCESS)

The TYPE(BLOCKADDR) command is used to specify IP addresses to be blocked until your firewall is updated. Once the firewall has been updated, they can be removed from the WebSphere MQ configuration.

The TYPE(ADDRESSMAP) command can be used to deny some or all connections and then you can write rules to enable specific whitelist rules as needed.

Certificate DN mapping

Both BlockIP2 and CHLAUTH can be used to set rules to map a certificate Distinguished Name (DN) to the MCAUSER value to be used. If you are using BlockIP2, you can specify a DN to be blocked in the configuration file by using the property SSL.

The following property allows connections from a DN whose organization's name is XYZ and maps them to MCAUSER mqusers:

SSL=O=XYZ;MCA=mqusers;

Here is the equivalent command for CHLAUTH:

SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('O="XYZ"') MCAUSER('mqusers')

Certificate DN blocking

Both BlockIP2 and CHLAUTH can be used to set rules to block access for certificate DN names. If you are using BlockIP2, the SSL property can be used.

The following property blocks connections from DNs whose organization's name is IBMINDIA:

SSL=O=IBMINDIA;BLOCK;

Using CHLAUTH, the following command blocks connections from DNs whose organization's name is IBMINDIA:

SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('O="IBMINDIA"') USERSRC(NOACCESS)

Client user ID mapping

Both BlockIP2 and CHLAUTH can be used to map the MCAUSER attribute of a server-connection channel, according to the original user ID received from a client.

If you are using BlockIP2, the CON property can be used to map the MCAUSER attribute according to the client-asserted user ID.

The following property maps the client-asserted user ID npardhas to the MCAUSER mquser:

CON=*;npardhas;MCA=mquser;

If you are using CHLAUTH, the following command maps the client-asserted user ID npardhas to the MCAUSER mquser:

SET CHLAUTH('*') TYPE(USERMAP) CLNTUSER('npardhas') MCAUSER('mquser')

This kind of mapping can also be done checking the IP address as well as the original user ID received from the client.

The following property maps connections with the client-asserted user ID npardhas and coming from IP address 10.*, and sets the MCAUSER to master:

CON=10.*;npardhas;MCA=master;

If you are using CHLAUTH, the following command allows connections coming from IP address 10.*, and maps the client-asserted user ID npardhas to the MCAUSER master:

SET CHLAUTH('*') TYPE(USERMAP) ADDRESS('10.*') CLNTUSER('npardhas') USERSRC(MAP) MCAUSER('master')

Client user ID blocking

Both BlockIP2 and CHLAUTH can be used to block specific user IDs. Using BlockIP2 you can block multiple user IDs from connecting to a specific server connection channel by specifying them with the BlockUsers property in the BlockIP2 configuration file. The BlockMqmUsers property in the BlockIP2 configuration file can be set to "Y" to block privileged users from using client channels.

The following property blocks the client-asserted user IDMQUSER1:

BlockUsers=MQUSER1;

The following property blocks privileged users:

BlockMqmUsers=Y;

CHLAUTH rules can also be set to prevent a specific client-asserted user ID from starting server connection channels. The following command blocks the client-asserted user ID MQUSER1 from starting server connection channel SYSTEM.DEF.SVRCONN:

SET CHLAUTH('SYSTEM.DEF.SVRCONN') TYPE(BLOCKUSER) USERLIST('MQUSER1')

You can use the command shown above to allow remote privileged users to connect to the queue manager by overriding the default rule that blocks them for a specific channel, but retains the default rule that blocks the other channels.

The following command blocks privileged users from using client channels:

SET CHLAUTH('*') TYPE(BLOCKUSER) USERLIST('*MQADMIN')

The value *MQADMIN means any user with privileged access on the queue manager. Putting this value in the USERLIST field will block any connection that is about to run as a privileged user.

Remote queue manager name mapping

The current version of BlockIP2 cannot perform remote queue manager name mapping. You can use CHLAUTH to set the MCAUSER attribute of a channel according to the queue manager from which the channel is connecting.

The following command maps the queue manager QM1 and sets the MCAUSER as QM1USER.

SET CHLAUTH('QM1.QM2') TYPE(QMGRMAP) QMNAME('QM1') USERSRC(MAP) MCAUSER('QM1USER')

Remote queue manager name blocking

The current version of BlockIP2 cannot perform remote queue manager name blocking. You can use a channel authentication record to prevent a remote queue manager from starting channels.

The following command blocks queue manager QM1 from connecting to the channel QM1.QM2.

SET CHLAUTH('QM1.QM2') TYPE(QMGRMAP) QMNAME('QM1') USERSRC(NOACCESS)

Porting the BlockIP2 configuration file into MQSC commands

This section shows the equivalent MQSC commands for the BlockIP2 configuration file shown in Figure 1.

  1. Block privileged users, and the user ID alis from using client channels.
    SET CHLAUTH('*') TYPE(BLOCKUSER) USERLIST('*MQADMIN','alis')
  2. Specific channel limitations:
    ALTER CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MAXINST(25)
    ALTER CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MAXINST(25)
    ALTER CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) MAXINST(25)
  3. Block user ID alis command was implemented in step 1.
  4. Allow clientuser1 when coming from 172.20.10.31, using the client user ID for MCAUSER
    SET CHLAUTH('*') TYPE(USERMAP) ADDRESS('172.20.10.31') CLNTUSER('clientuser1') USERSRC(CHANNEL)
  5. Allow tester when coming from IP address 10.*, and set MCAUSER to clientuser2.
    SET CHLAUTH('*') TYPE(USERMAP) CLNTUSER('tester') MCAUSER('clientuser2') ADDRESS('10.*')
  6. Allow connections from DN organization's name MQORG and map them to MCAUSER mqusers.
    SET CHLAUTH('*') TYPE(SSLPEERMAP) SSLPEER('O="MQORG"') MCAUSER('mqusers')
  7. Block connection attempts that don't match any of the other rules.
    SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)

Comparing CHLAUTH and BlockIP2

The following sections discuss specific differences between CHLAUTH and BlockIP2 in configuration, precedence order, validation, logging, per-node granularity, and self-signed certificates.

Comparison of configuration

To use BlockIP2, you need to download and extract it into an appropriate place for your platform. BlockIP2 configuration is managed by files on the WebSphere MQ server. Each channel can (and often should) have its own configuration file, or its own inline configuration. If you have a new application that wants to connect to the queue manager, you need to edit the BlockIP2 configuration file and update the security information.

Using CHLAUTH rules, you can consolidate configuration in a normal MQSC script. By creating the configuration as MQSC commands or in a single MQSC script, you can create a channel and set rules to provide required authentication to the channel at one time. The MQSC command DISPLAY CHLAUTH(*) ALL will display all CHLAUTH rules for a queue manager. This makes the WebSphere MQ administrator's job much easier and simpler to enable security and to implement it effectively.

Comparison of precedence

BlockIP2 searches the configuration file from top to bottom and it stops looking for any more matching rules as soon as one matches. Therefore, you need to place the most specific rules before the least specific ones in the configuration file.

The following table shows the order in which CHLAUTH checks for rule matches.

Table 1. Order of CHLAUTH checks
Order in which checks are madeTypeWhere
1 BLOCKADDR Listener
2 SSLPEERMAP, USERMAP, QMGRMAP and ADDRESSMAP Channel
3 Exits Channel
4 BLOCKUSER Channel

When an incoming connection request arrives at the WebSphere MQ queue manager, the following checks are made against CHLAUTH:

  1. The request is first processed by the listener where any BLOCKADDR rules are applied.
  2. The request is then passed to the responding channel program where the most specific mapping rule is applied, as described in the next section.
  3. After the mapping rules are applied, and then the channel security exit is run if one is defined.
  4. After processing the above rules the BLOCKUSER rules are applied.

If the connection request has not been denied in one of the previous steps, the channel startup is completed. When multiple mapping rules match the inbound channel, the most specific one takes precedence, as described in the following list:

  • Matching the channel name first allows specific rules to be in place for certain channels that might use a lower precedence mechanism.
  • The WebSphere MQ queue manager name or client user ID is generally included in the SSL/TLS DN. This makes the SSL/TLS DN a superset of the information and so a more specific piece of information than just the queue manager name or the client user ID, and thus it has a higher precedence.
  • You can have multiple queue managers or clients running from the same IP address; therefore, this has the lowest precedence.

The following table summarizes the precedence order within the mapping rules.

Table 2. CHLAUTH precedence order
Precedence orderIdentity mechanism
1 Channel name
2 SSL/TLS Distinguished name
3= Client-asserted user ID
3= Queue manager name
4 IP address

For more information about SSL/TLS Distinguished Names, see the topic Distinguished Names in the WebSphere MQ Knowledge Center.

Consider the following CHLAUTH rules to understand how precedence mapping works in channel authentication records.

1. SET CHLAUTH('*') TYPE(ADDRESSMAP) DESCR('MAP MCAUSER to TESTUSER for the IP Address 
coming from 10.121.*') ADDRESS('10.121.*') MCAUSER(TESTUSER)

2. SET CHLAUTH('*') TYPE(SSLPEERMAP) DESCR('MAP MCAUSER to IBMUSER coming with SSLPEER value IBM') 
SSLPEER('O="IBM"') MCAUSER(IBMUSER)

3. SET CHLAUTH('TEST.*') TYPE(USERMAP) DESCR('connection coming with client asserted id npardhas') 
CLNTUSER('npardhas') MCAUSER(PARDHA)

4. SET CHLAUTH('TEST.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('10.121.250.79') DESCR('connection 
coming with 10.121.250.79 to TEST.SVRCONN') MCAUSER(PARDHA)

If an incoming connection comes in over a channel named TEST.SVRCONN with a source IP address 10.121.250.79 and client user ID npardhas, then it would match the fourth rule because channel name has higher precedence than the other identity mechanisms.

If an incoming connection comes in over a channel named TEST.CLNT.SVRCONN with source IP address 10.121.250.79 and client user ID npardhas, then it would match rule number three since the channel name matches the partial channel rule name TEST.*.

Validating CHLAUTH rules using the RUNCHECK function

The DISPLAY CHLAUTH command can be used with the MATCH(RUNCHECK) option to test the rules from the console without making a real connection from a client or WebSphere MQ queue manager.

DISPLAY CHLAUTH(TEST.SVRCONN) MATCH(RUNCHECK) CLNTUSER('npardhas') ADDRESS('10.121.250.79') ALL
    10 : DISPLAY CHLAUTH(TEST.SVRCONN) MATCH(RUNCHECK) CLNTUSER('npardhas') ADDRESS('10.121.250.79') ALL
AMQ8878: Display channel authentication record details.
   CHLAUTH(TEST.SVRCONN)                   TYPE(ADDRESSMAP)
   DESCR(connection coming with 10.121.250.79 to TEST.SVRCONN)  
     CUSTOM( )                       ADDRESS(10.121.250.79)
   MCAUSER(PARDHA)                         USERSRC(MAP)
   ALTDATE(2014-06-16)                     ALTTIME(07.11.21)

The above display command shows what happens if an incoming connection comes in over a channel named TEST.SVRCONN with source IP address 10.121.250.79 and client user ID npardhas. The values provided to RUNCHECK must be fully specified; that is, there cannot be any wildcards.

You cannot test exits like BlockIP2 using the DISPLAY CHLAUTH MATCH(RUNCHECK) facility while you are trying to mimic inbound connections from clients or queue managers. When using MATCH(RUNCHECK), exits are not invoked and so any changes that they make will not be reflected in the result.

Comparison of logging

Both BlockIP2 and CHLAUTH can be configured to log whenever a connection refusal occurs on a channel. The following example is the error that gets written to the BlockIP2 log file if a connection is blocked.

A standalone Java client is running under user ID ganesh running with IP address 192.168.92.1 using a server connection channel TEST.SVRCONN on a Windows operating system. The client connects to a WebSphere MQ queue manager running with IP address 192.168.92.128 on a Linux® operating system.

The following code snippet shows the connection parameters that the Java client uses to connect to WebSphere MQ queue manager:

// Set MQ connection credentials to MQ Environment.
         MQEnvironment.hostname = 192.168.92.128;
         MQEnvironment.channel = TEST.SVRCONN;
         MQEnvironment.port = 1415;

In the following example, BlockIP2 exit is configured in the properties of server connection channel TEST.SVRCONN:

ALTER CHANNEL(TEST.SVRCONN) CHLTYPE(SVRCONN) 
SCYDATA('FN=c:\path\Blockspec.txt;') 
SCYEXIT('BlockIP2(BlockExit)')

The following is the property written in the specified BlockIP2 configuration file

CON=192.168.92.1;;BLOCK;

When the program runs, it can't connect successfully and the following message is written to the BlockIP2 logfile:

2011-03-10|18:29:54|-1221153904|Connection refused, Channel [TEST.SVRCONN] ConName [192.168.92.1] 
User [ganesh] was not accepted in CON=

When CHLAUTH generates channel events, they are considered to be EXCEPTION types, so you can enable them by setting the queue manager attribute CHLEV to either EXCEPTION or ENABLED. Whenever a connection is blocked, it generates an event. There are three ways a channel can be blocked by CHLAUTH. Each way will produce an event with a reason qualifier indicating the type of failure. The event messages and their reason qualifiers are listed in the following table.

Table 3. Blocked channel event messages
Event messageReason
MQRQ_CHANNEL_BLOCKED_USERIDChannel was blocked due to its asserted (or mapped) user ID being in the list to be refused.
MQRQ_CHANNEL_BLOCKED_ADDRESSChannel was blocked due to its IP address being in the list to be refused.
MQRQ_CHANNEL_BLOCKED_NOACCESSChannel was blocked due to its identity (IP address, SSL peer name, remote queue manager name or client user ID) being matched to a rule that says it is to be blocked.

MQRQ_CHANNEL_BLOCKED_USERID example

In this example, a standalone Java™ client is running with IP address 192.168.122.1 with user ID MUSR_MQADMIN using a server connection channel TEST.SVRCONN on a Windows operating system. The client connects to a WebSphere MQ queue manager running with IP address 192.168.122.82 on a Linux operating system. The following code snippet shows the connection parameters that the Java client uses to connect to WebSphere MQ queue manager:

// Set MQ connection credentials to MQ Environment.
         MQEnvironment.hostname = 192.168.122.82;
         MQEnvironment.channel = TEST.SVRCONN;
         MQEnvironment.port = 1414;

By default, there are three rules provided with your queue manager. When CHLAUTH is enabled, these rules will take effect. The third rule shown below disallows any privileged users from connecting to client channels.

DIS CHLAUTH(*)
     1 : DIS CHLAUTH(*)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
   CHLAUTH(*)                              TYPE(BLOCKUSER)
   USERLIST(*MQADMIN)

When the program runs, it fails to connect successfully, and an error message is captured in the error log:

AMQ9776: Channel was blocked by userid

EXPLANATION:
The inbound channel 'TEST.SVRCONN' was blocked from address '192.168.122.1' 
because the active values of the channel were mapped to a userid which 
should be blocked. The active values of the channel were 'MCAUSER
(MUSR_MQADMIN)CLNTUSER(MUSR_MQADMIN)'.

ACTION:
Contact the systems administrator, who should examine the channel 
authentication records to ensure that the correct settings have been configured. 
The ALTER QMGR CHLAUTH switch is used to control whether channel authentication 
records are used. The command DISPLAY CHLAUTH can be used to
query the channel authentication records.

WebSphere MQ generates an event message to the channel event queue.

Figure 2. MS0P view of a MQRQ_CHANNEL_BLOCKED_USERID event

MQRQ_CHANNEL_BLOCKED_NOACCESS example

In this example, a standalone Java client under user ID pardha is running with IP address 192.168.122.1, using a server connection channel SYSTEM.DEF.SVRCONN on a Linux operating system. The client connects to a WebSphere MQ queue manager running with IP address 192.168.122.82 on a Windows operating system. The following code snippet shows the connection parameters that the Java client uses to connect to WebSphere MQ queue manager:

// Set MQ connection credentials to MQ Environment.
         MQEnvironment.hostname = 192.168.122.82;
         MQEnvironment.channel = SYSTEM.DEF.SVRCONN;
         MQEnvironment.port = 1414;

By default, there are three rules provided with your queue manager. When CHLAUTH is enabled, these rules will take effect. The second rule shown below disables the use of any system-related channels.

dis chlauth(*)
     3 : dis chlauth(*)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
   CHLAUTH(*)                              TYPE(BLOCKUSER)
   USERLIST(*MQADMIN)

When the program runs, it fails to connect successfully, and an error message is captured in the error log:

AMQ9777: Channel was blocked

EXPLANATION:

The inbound channel 'SYSTEM.DEF.SVRCONN' was blocked from address '192.168.122.1' 
because the active values of the channel matched a record configured with USERSRC(NOACCESS). 
The active values of the channel were 'CLNTUSER(pardha)'.

ACTION:

Contact the systems administrator, who should examine the channel authentication records 
to ensure that the correct settings have been configured. The ALTER QMGR CHLAUTH switch 
is used to control whether channel authentication records are used. The command 
DISPLAY CHLAUTH can be used to query the channel authentication records.

The following event message is written to the channel event queue.

Figure 3. MS0P view of a MQRQ_CHANNEL_BLOCKED_NOACCESS event

MQRQ_CHANNEL_BLOCKED_ADDRESS example

A standalone Java client under user ID pardha is running with IP address 192.168.122.1 on a Linux operating system. The client connects to a WebSphere MQ queue manager running with IP address 192.168.122.82 using a server connection channel TEST.SVRCONN. The following code snippet shows the connection parameters that the Java client uses to connect to WebSphere MQ queue manager:

// Set MQ connection credentials to MQ Environment.
         MQEnvironment.hostname = 192.168.122.82;
         MQEnvironment.channel = TEST.SVRCONN;
         MQEnvironment.port = 1415;

To create a channel authentication record that blocks IP address 192.168.122.1 from connecting to the queue manager as a client, use the following command:

SET CHLAUTH('*') TYPE(BLOCKADDR) ADDRLIST('192.168.122.1')

When the program runs, it fails to connect successfully and an error message is captured in the error log:

AMQ9782: Remote connection blocked.

EXPLANATION:

A connection from IP address '192.168.122.1' was blocked because it matched 
the blocking address rule 192.168.122.1'.

ACTION:

Verify that the channel authentication blocking rules are correct. If necessary 
modify the rules to allow the inbound connection using the SET CHLAUTH command. 
The ALTER QMGR CHLAUTH switch is used to control whether channel authentication 
records are used. Refer to the commands section of the WebSphere MQ Information 
Center for more information on the specification of the IP address parameter.

The following event message is written to the channel event queue.

Figure 4. MS0P view of a MQRQ_CHANNEL_BLOCKED_ADDRESS event

Comparison of per-node granularity in securing the clusters

If your WebSphere MQ cluster network contains a mix of platforms, then BlockIP2 requires an additional channel auto-definition exit to provide granular security in a cluster environment. CHLAUTH records can provide per-node granularity in securing the cluster.

The setup tasks to allow per-node granularity in securing the cluster are as follows:

  • Create authentication rules for the full repository queue managers using CHLAUTH records.
  • Create authorization profiles for the full repository queue managers using AUTHREC records.
  • Configure partial repository queue managers using CHLAUTH records.
  • Create authorization profiles for the cluster member queue managers using AUTHREC records.

Comparison of self-signed certificates

BlockIP2 has the ability to enforce a policy to block self-signed certificates from connecting to the queue manager. The following property can be used to allow self-signed certificates:

AllowSelfSignedCertificates=Y;

There is no equivalent functionality provided by WebSphere MQ. The administrator can validate that self-signed certificates in the keystore are configured without the ability to sign other certificates.

Putting it all together

The following table summarizes the functionalities of BlockIP2 and WebSphere MQ V7.1.

Table 4. Comparison of channel authentication records and BlockIP2
FunctionalitiesIBM WebSphere MQBlockIP2
IP address mapping Yes - CHLAUTH Yes - CON
IP address blocking Yes - CHLAUTH Yes - CON
Certificate DN mapping Yes - CHLAUTH Yes - SSL
Certificate DN blocking Yes - CHLAUTH Yes - SSL
Client user ID mapping Yes - CHLAUTH Yes – CON
Client user ID blocking Yes - CHLAUTH Yes – CON
Remote queue manager name mapping Yes - CHLAUTH No
Remote queue manager name blocking Yes - CHLAUTH No
DNS filtering No, but introduced in IBM MQ V8 Yes - See Note 1
Distinguish between self and CA-signed certificates No Yes
Channel limitations Yes - MAXINST Yes - MAXCHL
Allow per-node granularity in securing the clusters Yes - CHLAUTH Yes - See Note 2
Logging of failures Yes - error messages and event messages Yes - log file
Logging of successful connections Partially; channel-started events, but not for SVRCONNs Yes - log file
Failure impact Full support from IBM No support, your own risk

Notes

1. BlockIP2 has the ability to filter DNS names and IP addresses, whereas CHLAUTH filters only IP addresses in V7. In WebSphere MQ V8, CHLAUTH filters both DNS names and IP addresses.

2. For BlockIP2 to provide security on heterogeneous clusters, you need to have a channel auto-definition (CHAD) exit. Using CHLAUTH, security on heterogeneous clusters can be implemented independently for each queue manager, making the overall solution simpler and more stable.

Conclusion

The channel authentication records feature in WebSphere MQ is designed to increase messaging security and remove the need for additional ISV extensions to implement security. This article compared the functionalities of BlockIP2 version 2.93 and channel authentication records using WebSphere MQ V7.1. Channel authentication records provide similar functionalities provided by BlockIP2 and have full support from IBM.

Acknowledgements

The author would like to thank Morag Hughson, WebSphere MQ Architect for IBM, for her helpful technical review of this article.

Resources


Downloadable resources


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Security
ArticleID=978348
ArticleTitle=Comparing BlockIP2 with Channel Authentication Records for WebSphere MQ Security
publish-date=07242014