Pdf Mq Channel Authentication Records For Sale

1. Mq Channel Authentication
2. Pdf Mq Channel Authentication Records For Sale Free
3. Pdf Mq Channel Authentication Records For Sales
4. Pdf Mq Channel Authentication Records For Sale

When using MQ 7.1 or 7.5 queue managers, if the MQ JMS client in WAS gets a RC 2035, one possibility is that the 'channel authentication records' are enabled. For more details see the following technote.

• Channel Authentication –MQ Explorer Next follow the steps to set up your channel authentication rule. In the Channel profile screen you can put the name of a channel or a generic name –For example: “INCOMING.CHANNEL” or “System.*” The next screens allow you to put the filter rules in for the CHLAUTH.
• The channel list is saved in the mq.autodiscovery.channel.list property. The tool saves the report to a file named MQDiscoveryUtility.log in the /logs directory of the MQMonitor agent. The tool appends all the MQMonitor.properties changes to the same file in interactive and non-interactive mode.

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

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

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

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:

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:

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:

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:

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:

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:

Here is the equivalent command for CHLAUTH:

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:

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

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:

If you are using CHLAUTH, the following command maps the client-asserted user ID npardhas to the 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:

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:

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:

The following property blocks privileged users:

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:

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:

Mq Channel Authentication

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.

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.

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.
2. Specific channel limitations:
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
5. Allow tester when coming from IP address 10.*, and set MCAUSER to clientuser2.
6. Allow connections from DN organization's name MQORG and map them to MCAUSER mqusers.
7. Block connection attempts that don't match any of the other rules.

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 made	Type	Where
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 order	Identity 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.

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.

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:

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

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

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

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 message	Reason
MQRQ_CHANNEL_BLOCKED_USERID	Channel was blocked due to its asserted (or mapped) user ID being in the list to be refused.
MQRQ_CHANNEL_BLOCKED_ADDRESS	Channel was blocked due to its IP address being in the list to be refused.
MQRQ_CHANNEL_BLOCKED_NOACCESS	Channel 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:

Pdf Mq Channel Authentication Records For Sale Free

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.

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

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

Pdf Mq Channel Authentication Records For Sales

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:

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.

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

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

Pdf Mq Channel Authentication Records For Sale

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:

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:

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

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:

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

Functionalities	IBM WebSphere MQ	BlockIP2
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

• WebSphere and CICS Support blog
  This WebSphere support blog provides blogposts about CHLAUTH and WebSphere MQ.
• IBM WebSphere MQ V7.5 Knowledge Center
  The official source for WebSphere MQ V7.5 technical documentation.
• MS0P SupportPac - Extended Management Plug-ins
  A set of MQ plug-ins that extend capabilities for queue manager configuration.
• Store and forward: A technical blog on WebSphere MQ and MQ security
  A blog by T. Rob Wyatt, former WebSphere MQ Product Manager at IBM, covering WebSphere MQ topics.

Downloadable resources

Comments

Sign in or register to add and subscribe to comments.