这行：
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('mq-user')说以下内容：
- 对于连接请求
TEST_CHANNEL
… - 源自 任何 IP地址…
- 将MCAUSER设置为
mq-user
换句话说，启用通道，以使任何连接都继承特权，
mq-user无论它们起源于何处以及它们所呈现的身份如何。因此，您看到的行为是基于上述
CHLAUTH规则的预期行为。
列出的规则还有其他一些问题：
- 使用
PRINCIPAL
而不是GROUP
。在非Windows服务器上，如果指定PRINCIPAL
发生的情况，则QMgr将查找该ID，查询其主要组，然后根据该组设置授权。因此，如果mq-users
具有staff
或的主要组users
，则该组将获得授权，而mq-users
不是您想要的。始终使用，group
以便通过setmqaut
或获得预期的结果AUTHREC
。 ALL
在QMgr上进行授予使ID /组具有管理性。QMgr级别的特权之一是SET
，具有SET
权限的组中的任何用户都可以设置授权控制列表等。因此，即使你只授予AUTHADD(INQ,DSP,PUT)
的mq-users
ID可以提交PCF命令授予所有访问所有对象。如果您只需要批准，CONNECT
并INQUIRE
在QMgr上。- 有一个假设（实际上是黑体）表明您将需要通过用户凭证。请注意，如果您提供了用户ID和密码，WMQ不会对其进行验证。它接受您声明的ID。密码字段可用于退出，可用于根据LDAP或本地OS验证ID和密码。可以从第三方购买或退出此类出口，但是基本WMQ不会使用密码进行任何操作。如果您
USERSRC(CHANNEL)
在映射上指定了ID，那么您的ID将被使用，并且很可能被拒绝。但是拒绝的原因可能是因为它在mqm
组中（默认CHLAUTH
规则阻止了它），或者是因为它所在的组中没有AUTHREC
记录。
欲了解更多有关硬化WMQ，还有一些收集的资源在这里。该 硬化的WebSphere MQ
表现为V7.0。尽管v7.1具有新的控件，但其原理保持不变：
- 使用IP过滤（对于连接来自锁定数据中心的应用或QMgr），SSL / TLS和/或出口对连接进行身份验证
MCAUSER
通过在通道中对其进行硬编码或通过使用出口或CHLAUTH
规则动态设置它来将已认证的身份映射到一个值- 管理连接和高价值应用程序应使用TLS进行身份验证
