WebSphere MQ v7.1安全性用户凭据

这一行：

SET CHLAUTH（TEST_CHANNEL）TYPE（ADDRESSMAP）ADDRESS（*）MCAUSER（'mq-user'）

说明以下内容：

• 对于请求 TEST_CHANNEL的连接 ...


• 源自任何 IP地址...


• 将MCAUSER设置为 mq-user

• For connections requesting TEST_CHANNEL...
• Originating from any IP address...
• Set the MCAUSER to mq-user

换句话说，启用频道，使任何连接都继承 mq-user 的权限>无论他们来自何处以及他们所呈现的身份。因此，您看到的行为是基于上面的 CHLAUTH 规则的预期行为。

In other words, enable the channel such that any connections inherit the privileges of mq-user regardless of where they originate and what identity they present. So the behavior you are seeing is the expected behavior based on the CHLAUTH rule above.

还有一些其他行为列出的规则存在问题：

There are a few other problems with the rules as listed:

• 使用 PRINCIPAL 而不是组。在非Windows服务器上，如果指定 PRINCIPAL ，会发生的情况是QMgr查找该ID，查询其主要组，然后根据该组设置授权。因此，如果 mq-users 的主要组员工或用户这是获得授权的而不是 mq-users ，可能不是你想要的。始终使用 group ，以便获得您想要的结果 setmqaut 或 AUTHREC 。


• 在QMgr上授予 ALL 使ID /组管理。 QMgr级别的一个特权是 SET ，并且具有 SET 权限的组中的任何用户都可以设置等等事情，授权控制列表。所以，即使您只授予 AUTHADD（INQ，DSP，PUT）， mq-users ID也可以提交PCF命令授予对所有对象的所有访问权。如果您需要，只需在QMgr上授予 CONNECT 和 INQUIRE 。


• 有一个假设（实际上是粗体）表示您可能需要传递用户凭据。请注意，如果您提供用户ID和密码，WMQ不会验证用户ID和密码。它接受您声明的ID。密码字段可用于退出，可用于验证ID或密码，例如LDAP或本地操作系统。这样的退出可以从第三方购买或写入，但基本WMQ不对密码做任何事情。如果您在映射上指定了 USERSRC（CHANNEL），那么您的ID将被使用并且很可能被拒绝。但拒绝可能是因为它在 mqm 组中（被默认的 CHLAUTH 规则阻止）或者因为它所在的组没有 AUTHREC 记录。

• The use of PRINCIPAL rather than GROUP. On non-windows servers if you specify PRINCIPAL what happens is that the QMgr looks up that ID, queries its primary group and then sets authorizations based on that. So if mq-users has a primary group of staff or users that that is what gets authorized instead of mq-users and is probably not what you intended. Always use group so that you get the result you intend with setmqaut or AUTHREC.
• Granting ALL on the QMgr makes the ID/group administrative. One of the privileges at the QMgr level is SET and any user in a group with SET rights can set, among other things, authorization control lists. So even though you only granted AUTHADD(INQ,DSP,PUT) the mq-users ID can submit PCF commands to grant all access to all objects. Only grant CONNECT and INQUIRE on the QMgr if that's all you need.
• There's an assumption stated (in bold, actually) that you would have expected to be required to pass user credentials. Please be aware that WMQ does not validate a user ID and password if you do provide them. It accepts the ID that you assert. The password field is available to exits which can be used to validate the ID and password against, for example, LDAP or the local OS. Such an exit can be purchased from a 3rd party or written but base WMQ doesn't do anything with the password. Had you specified USERSRC(CHANNEL) on the mapping, then your ID would have been used and most likely rejected. But the rejection would have been either because it is in the mqm group (which is blocked by a default CHLAUTH rule) or because there are no AUTHREC records for the group it is in.

有关加强WMQ的更多信息，此处收集了大量资源。 强化WebSphere MQ 演示文稿来自v7.0。虽然v7.1有新控件，但是主体保持不变：

For more about hardening WMQ, there are a number of resources collected here. The Hardening WebSphere MQ presentation is from v7.0. Although v7.1 has new controls, the principals remain the same:

• 使用IP过滤验证连接（对于连接的应用程序或QMgrs）源自锁定的数据中心），SSL / TLS和/或退出


• 通过硬件将经过身份验证的身份映射到 MCAUSER 值在通道中编码或使用退出或 CHLAUTH 规则来动态设置它


• 管理连接和高价值应用程序应该是使用TLS进行身份验证

• Authenticate the connection using IP filtering (for apps or QMgrs where the connection originates in a locked datacenter), SSL/TLS and/or an exit
• Map the authenticated identity to an MCAUSER value by hard-coding it in the channel or by using an exit or CHLAUTH rule to dynamically set it
• Administrative connections and high-value applications should be authenticated using TLS