内容


任务:消息

理解 WebSphere MQ 授权和 setmqaut 命令

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 任务:消息

敬请期待该系列的后续内容。

此内容是该系列的一部分:任务:消息

敬请期待该系列的后续内容。

配置文件、实体和分组

从最简单的形式来说,IBM WebSphere MQ 授权控制将为单一对象的单一实体赋予一组权限。但是在实践中,赋予特定用户的有效授权可能来自一些访问控制实体(在 WebSphere MQ 术语中称作配置文件),它们可能已经应用于多个分组。有效访问是指结合所有可应用的配置文件,包括所有可应用的分组或帐户。要理解所有这些知识点,您需要了解配置文件、帐户和分组之间的交互,以及用于管理这些设置的工具。

为了演示配置文件与实体之间的不同交互,请看以下三个用例:

  • 第一个用例 中,一个应用程序将建立连接、发起请求并等待回复。可以使用一些配置文件来建立这个简单的模式。
  • 第二个用例 是来自相邻队列管理器的连接。您要求访问将消息保存到所有用户定义的队列中,但不会为相邻队列管理器赋予管理权限。这个用例将展示不同访问控制列表与特定队列集之间的交互。
  • 最后一个用例 将展示如何累计来自多个源的访问。在此场景中,一个虚构的开发人员会将 “Foo” 项目迁移到 “Bar” 项目上。由于 Foo 和 Bar 应用程序之间将彼此进行交互,因此它们都需要访问一些相同的队列,但权限各不相同。您将看到与开发人员帐户相关联的分组成员身份在更新时,访问权限将如何随时间不断变化。

在深入探讨之前,我们有必要在此上下文中给一些术语实体的定义。授权可以应用若干个不同的层次。其中,最低的层次是单独的帐户。此帐户可能属于某个人类用户、应用程序、系统工具、信息代理或者监控器。通常,属于人类的帐户被称作用户 ID ,而应用程序和工具所使用的帐户则被称作 服务帐户。当差异无关紧要时,可以将帐户更加通用地表示为主体(principal),即 setmqaut 命令中的 –p 选项。

授权还可以应用于分组级别。分组表示零个或多个主体。在一些模型中,比如 Windows® Active Directory,甚至可以将权限授予包含域分组的本地分组,其中还包含主体。

在本文中,实体表示授权规则可以应用到的任何内容。根据平台和帐户管理工具,授予权限的实体还可以是单独帐户或本地分组。当主体与分组之间的差异无关紧要时,相关对象可表示为实体。

归纳如下:

  • 用户 ID 和服务帐户是主体的一种。
  • 主体和分组是实体的一种。

在本文的其余部分,我将使用最适用的术语。

用例 #1:授权应用程序

还记得在本用例中,应用程序需要连接到队列管理器,添加一个消息到队列中,并获得回复。远程应用程序通过 SVRCONN 通道建立连接与本地应用程序采用绑定模式建立连接所需的权限是相同的。惟一的差异在于 WebSphere MQ 获取主体的方式。

在本地绑定模式连接中,主体是与连接到队列管理器的进程相关联的帐户。由于连接到的进程在本地运行,因此 WebSphere MQ 可以通过查找进程表来获取进程所有者。经过操作系统验证后的帐户是可以信赖的。

对于使用客户机通道连接的远程应用程序来说,主体是通道的 MCAUSER 属性中的帐户。如果 MCAUSER 硬编码在通道定义中,或者经过验证,则该帐户可以信赖。

应用程序服务帐户 applefruit 分组的成员,授予所需权限的命令应如下所示:

setmqaut -m VENUS -t qmgr -g fruit -all +inq +connect
setmqaut -m VENUS -t queue -g fruit -n FRUIT.REQUEST -all +put +inq
setmqaut -m VENUS -t queue -g fruit -n FRUIT.REPLY -all +get +browse +inq

指定队列管理器

–m 选项还用于指定将应用命令的队列管理器。如果定义了默认的队列管理器,则可以省略 –m 选项,但不建议这样做。在需要考虑安全性的情况下,最佳的方式是使用最明确的命令语法,以实现所需的结果。指定 –m 选项需要掌握目标队列管理器的信息。省略该选项也需要掌握相同的信息,但还需要管理员明确当前设定的默认本地队列管理器。在任何情况下,使用 –m 选项来明确指定队列管理器都会更加简单和可靠。

授权分组和主体

示例中的下一个参数是 –g,它用于指定分组。虽然 setmqaut 命令接受使用 –p 选项来指定帐户,但 –g 分组选项通常是您需要的。其原因在于,–p 将根据平台表现出不同的行为。在 UNIX® 和 Linux® 平台上,队列管理器将查找在 –p 选项中指定的主体,获取指定主体的主要分组,然后将配置文件应用于该分组。如果主体使用 staff 作为其主要分组,并使用 apple 作为次要分组,则使用 -p 选项时将为 staff 分组授权。

我见过许多在 UNIX 平台上使用 –p 选项的情况,并且帐户的主要分组会随时间变化。每次在分组成员身份更改后更新授权时,配置文件都将应用于当前分组。这时,应用程序不会出现故障,因此不需要提醒管理员授予了过度权限。在除 Windows 以外的平台上指定 –p 选项会执行隐式操作,而非明确操作。正如前面讨论默认队列管理器时所提到的,明确操作始终是首选。

在 Windows 平台上,–p 选项的行为则不同。它实际上会解析为单独的帐户。但是,这并不是一成不变的,因此在 Windows 主机上使用 –p 选项时仍然需要格外注意。

我们来考虑 Windows 将如何解析针对 applid 主体的查询。首先,搜索本地 Security Account Manager (SAM) 数据库,查找匹配帐户。如果找到了本地帐户,则始终使用它。但是,如果未找到本地帐户,则 Windows 服务器将查询它所信任的所有域。搜索这些域的顺序是不确定的,因此如果匹配帐户存在于多个域中,则无法预先知道哪个帐户实例将解析查询。

这一点非常重要,因为在执行 setmqaut 命令时,所创建的配置文件将包含 Security ID (SID),而不是字符串版本的帐户名。SID 是特定域中特定帐户的全局惟一标识符。如果 applid 同时存在于 DomainA 和 DomainB 中,则每个实例都会有与之相关的惟一 UID。setmqaut 命令将接收解析执行命令的实例的 SID。这可能是也可能不是在运行时查找帐户时返回的相同的实例。

在指定主体时可以解决这种不明确性,其方法是通过所需的域名限定它。setmqaut 命令和 MCAUSE 通道属性的正确格式是 user@domain,其中,domain 是实际域名或本地主机的名称。在使用这种格式时,Windows 会正确解析所需域中的主体,即使一个帐户在多个位置有相同的名称。

但是,不能通过这种方式来指定分组。WebSphere MQ 认可的惟一分组是在托管队列管理器的服务器上本地定义的分组。因此,如果 Windows 队列管理器的授权将基于分组,则相关主体必须属于本地分组或者属于本地分组的成员域分组。

考虑到这些原因,我建议只在 Windows 主机上使用 setmqaut –p 选项,然后使用 user@domain 格式完全限定帐户。以下示例展示了 –p 选项的建议使用方法:

setmqaut -m VENUS -t qmgr -p user1@mqhost -all +inq +connect

权限的规范

setmqaut 命令中的最后一个参数是将授权的权限。注意,此处提供的示例都包含 -all,后面紧跟其他权限,比如 +inq+connect。其原因在于,setmqaut 命令是可以累计的。

举例来说,考虑以下命令的结果:

C:\>setmqaut -m VENUS -t qmgr -g fruit +dsp 
The setmqaut command completed successfully. 

C:\>setmqaut -m VENUS -t qmgr -g fruit +inq +connect 
The setmqaut command completed successfully. 

C:\>dspmqaut -m VENUS -t qmgr -g fruit 
Entity fruit has the following authorizations for object VENUS: 
	inq 
	connect 
	dsp

注意,前两条命令的结果是结合在一起的。当 –all 添加到第二条命令之后,它会替换之前设置的授权,而不是添加权限。

C:\>setmqaut -m VENUS -t qmgr -g fruit +dsp 
The setmqaut command completed successfully. 

C:\>setmqaut -m VENUS -t qmgr -g fruit +inq +connect 
The setmqaut command completed successfully. 

C:\>dspmqaut -m VENUS -t qmgr -g fruit 
Entity fruit has the following authorizations for object VENUS: 
	inq 
	connect

其目的通常在于,setmqaut 命令会替换之前的任何配置文件,而不是继续添加配置文件。–all 参数将确保这一过程的顺利执行。

+inq 的重要性

注意,以上示例都提供了 +inq。其原因在于,WebSphere MQ 对象的一些属性专用于使用这些对象将信息传递给应用程序。举例来说,BOQNAME 属性可以保存回退(backout)队列的名称(该队列可以包含问题消息)。BOQTHRESH 属性包含在将消息存放到回退队列之前可以回退(backout)的次数。

查询可以在许多情况下发生,即使不受应用程序代码的控制。举例来说,JMS 类将查询应用程序是否明确执行 BOQNAME 和 BOQTHRESH。通用规则是,被适当允许连接到队列管理器的任何实体都应该授予 +inq 权限。

用例 #1 总结

在第一个用例中,单一分组 fruit 授予了连接到队列管理器、查询请求队列以及获取、浏览和查询回复队列的权限。在此示例中,配置文件与所应用的对象之间存在一一对应的关系。

默认情况下,不在 mqm 分组中的任何主体都不具备访问权限。运行三个命令之后,fruit 分组的成员将限制于特定操作。仅为 fruit 分组的成员的主体将不能执行其他活动。

用例 #2:相邻列队管理器

此用例是基本 WebSphere MQ 管理的基石。其目标是为相邻队列管理器赋予广泛的权限,允许将消息添加到本地队列管理器的用户定义队列中,同时赋予管理权限。

来自其他队列管理器的通道(在 WebSphere MQ 术语中称作 MCA 通道)有三种形式:RCVR、RQSTR 和 CLUSRCVR。您可能知道,所有入站通道都具有队列管理器的完整权限,因此可以访问所有队列。为了限制访问,需要强制通道使用低权限帐户。为此,可以将通道的 MCAUSER 值设置为适当帐户。

专用于此目的的任何帐户都可以,但我倾向于选择易于识别有管理权限的帐户名。考虑到这些原因,我为 RCVR、RQSTR 和 CLUSRCVR 通道使用 mqmmca 帐户。mqm 部分可联系到用于管理 WebSphere MQ 的 mqm 帐户。希望帐户管理员已经将 mqm 帐户和分组作为管理帐户对待并限制对它们的访问。其他名称为 mqm* 的帐户和分组也具有相同的控制。帐户名的 mca 部分表示帐户特定于 MCA 通道。同样,我为 MQI 通道(多称作客户机或 SVRCONN 通道)使用类似的 mqmmqi 帐户。两种通道的权限需求稍有不同,因此创建不同的帐户和分组是非常重要的。这一点将在下一个用例中详细解释。

因此,对于名称为 mqmmca 的帐户和分组,应该如何将它赋予大量队列呢?在创建配置文件之前,帐户不具有权限。但使用第一个用例中的技巧需要为通道访问的每一个队列都创建一个配置文件。这不仅极为耗费人力工作,而且非常脆弱不堪,因为每个队列都需要一个配置文件;忘记创建配置文件会造成应用程序中断。更加合理的方法是建立一个默认的 “允许所有(allow-all)” 的策略,让一个配置文件来管理多个队列。幸运的是,setmqaut 提供了相应配置。在配置文件名称中使用通配符可以实现通用的配置文件。

通用的配置文件

WebSphere MQ 对象名通常由点分隔的节点构成。setmqaut 命令支持在名称中使用问号来表示一个字符,或者在节点中使用星号来表示零个或多个字符。举例来说:AB.?D 可以匹配名称为 AB.CD、AB.DD、AB.ED 的对象。

星号可匹配由点分隔的零个或多个字符。举例来说,ABC.*.JKL 可以表示对象 ABC.DEF.JKL 和 ABC.GHI.JKL。注意,配置文件将匹配一个名称为 ABC..JKL 的队列,因为它有三个节点,即使中间的节点没有字符。但是 ABC.*.JKL 不能匹配名称为 ABC.JKL 的队列,因为它的名称中只有两个节点。

可以在相同配置文件中使用多个问号和星号。举例来说,配置文件 ???.*.* 将匹配共包含三个节点且第一个节点有三个字符的名称。

由两个星号构成的通配符将匹配零个或多个节点,并且可以在名称的开头、中间或结尾使用。有效的示例包括:

表 1. setmqaut 命令中的通配符
**.REPLY匹配最后一个节点为 .REPLY 的所有名称
PAY.**匹配第一个节点为 PAY. 的所有名称。
PAY.**.REPLY匹配第一个节点为 PAY.、最后一个节点为 .REPLY 且中间可包含任意个节点的名称。
**匹配所有名称。

一些示例将帮助您更好地理解这一点。此处,两个星号用于表示队列名称开始处的零个或多个节点。请注意,两个星号将匹配零个或多个节点,而不是一个或多个节点。这说明在最后一个示例中,名称中包含一个或多个节点的 REPLY 都将被赋予权限。

C:\>setmqaut -m VENUS -t queue -n **.REPLY -g fruit -all +inq +dsp 
The setmqaut command completed successfully. 

C:\>dspmqaut -m VENUS -n .REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object .REPLY: 
	inq 
	dsp 

C:\>dspmqaut -m VENUS -n ..REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object ..REPLY: 
	inq 
	dsp 

C:\>dspmqaut -m VENUS -n REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object REPLY: 
	inq 
	dsp

在下一个示例中,两个星号可表示名称中间的多个节点。

C:\>setmqaut -m VENUS -t queue -n PAY.**.REPLY -g fruit -all +inq +dsp 
The setmqaut command completed successfully. 

C:\>dspmqaut -m VENUS -n PAY.ROLL.REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object PAY.ROLL.REPLY: 
	inq 
	dsp 

C:\>dspmqaut -m VENUS -n PAY.OVER.DRAFT.REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object PAY.OVER.DRAFT.REPLY: 
	inq 
	dsp
                
C:\>dspmqaut -m VENUS -n PAY..REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object PAY..REPLY: 
	inq 
	dsp 

C:\>dspmqaut -m VENUS -n PAY.REPLY -t queue -g fruit 
Entity fruit has the following authorizations for object PAY.REPLY: 
	inq 
	dsp 

C:\>dspmqaut -m VENUS -n PAYREPLY -t queue -g fruit 
Entity fruit has the following authorizations for object PAYREPLY:

注意,在最后一个示例中,PAY.**.REPLY 并不会匹配名称 PAYREPLY,因为配置文件需要至少 PAY 和 REPLY 两个节点,至少使用一个点分隔。同样,配置文件 PAY**REPLY 也是无效的,因为两个星号必须与其他字符分隔开。

重叠配置文件

通过使用通用配置文件,可以将多个配置文件应用于相同对象。举例来说,配置文件 PAY.**、PAY.**.REPLY 和 PAY.ROLL.REPLY 都可以应用于名称为 PAY.ROLL.REPLY 的队列。在这种情况下,其规则是最具体的配置文件将用于授权检查。在本例中,没有通配符的配置文件是最具体的,因此是优先的。在其余两个配置文件中,PAY.**.REPLY 优先于 PAY.**,因为任何匹配名称都将匹配五个特定的字符(而不是三个特定的字符)。

重叠配置文件的使用可允许您为第二个用例构建授权模式。通道要求一个配置文件连接到队列管理器,另一个配置文件建立到所有队列的访问,而其他特定配置文件则进一步限制对队列的管理权限。这一组配置文件如下所示:

setmqaut -m VENUS -g mqmmca -t qmgr -all +connect +inq +setall
setmqaut -m VENUS -g mqmmca -n '**' -t queue -all +put +setall
setmqaut -m VENUS -g mqmmca -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +none
setmqaut -m VENUS -g mqmmca -n SYSTEM.DEFAULT.INITIATION.QUEUE -t queue -all +none 
setmqaut -m VENUS -g mqmmca -n SYSTEM.CLUSTER.TRANSMIT.QUEUE -t queue -all +none

‘**’ 配置文件将为通道建立权限,以便将消息添加到任何队列中。由于其他配置文件更加具体,因此它们将覆盖此配置文件,而通道将无法将消息添加到命令队列、默认启动队列或集群传输队列。

这是限制相邻队列管理器的管理权限的最小基本配置,此处仅用于演示。在实践中,此授权模式还将限制对任何用户定义的启动队列、传输队列和许多 SYSTEM.** 队列的访问。如果队列管理器参与到集群中,则需要通过 CLUSRCVR 通道访问 SYSTEM.CLUSTER.COMMAND.QUEUE 的权限。另一方面,相邻队列管理器几乎永远都不需要对 SYSTEM.ADMIN.COMMAND.QUEUE 的访问权限。

使用 +setall 权限

MCA 通道需要针对队列管理器和队列的 +setall 权限。其原因在于通道代理会保留消息描述符的内容,它会设置所有字段以匹配来自发送队列管理器的消息。这包括消息 PUT 日期和时间,以及用户 ID。这不同于不信任普通应用程序设置消息上下文字段,而是从队列管理器认为的合适的值继承这些字段。因此,任何 RQSTR、RCVR 或 CLUSRCVR 类型的通道都需要 +setall。

虽然可以像其他内部队列管理器组件那样信任 MCA 通道代理,但 MQI 通道代理则不尽然。这是因为 MQI 通道代理是由可访问整个 WebSphere MQ API 的远程应用程序驱动的。虽然远程应用程序有时需要设置消息头部字段,但这只是例外情况,而不是规则。作为规则,不能将 +setall 权限赋予 SVRCONN 类型的通道。

用例 #2 总结

可以使用单一分组中的单一帐户来为相邻队列管理器赋予权限。如果此例发生在 Windows 主机上,则可以忽略分组而直接为主体授权,而不用让它成为分组的成员。无论何种情况,重叠配置文件的技巧都是先建立一个 “允许所有” 的默认策略,然后再使用更加严格的限制来重叠特定队列。通用配置文件的使用可允许对新创建的队列自动执行策略,并通过非常细的粒度来指定例外情况。

用例 #3:虚构的开发人员

在上一个用例中,授权主体的权限仅由一个配置文件驱动。如果有两个配置文件匹配相同对象,则最具体的配置文件将优先,并完全覆盖另一个配置文件中指定的权限。下一个示例展示了另一个情况:当所涉及的主体是多个分组的成员并且这些分组具有不同的权限时,可以累计多个配置文件中的权限。

在本例中,一个虚构的开发人员将使用用户 ID alice。由于 Alice 正在负责 Foo 项目,因此 alice 用户 ID 当前位于 “foo” 分组。Foo 应用程序将请求 Bar 应用程序中的服务,并期望获得回复。因此,Alice 应该具备对 FOO.** 队列的访问权限,以及对 BAR.**.RQST 队列的有限访问权限。可以使用以下配置文件来赋予此访问权限:

setmqaut -m VENUS -t qmgr -g foo -all +inq +connect
setmqaut -m VENUS -t queue -g foo -n 'FOO.**' -all +inq +get +browse
setmqaut -m VENUS -t queue -g foo -n 'BAR.**.RQST' -all +put

由于 Foo 应用程序是 Bar 服务的主要用户,并且由于 Alice 是关于 Foo 一切方面的常驻专家,因此 Bar 应用程序的项目经理聘用她作为新的 Quality Assurance 主管。作为迁移的一部分,alice 用户 ID 将被添加到具有以下权限的 bar 分组:

setmqaut -m VENUS -t qmgr -g bar -all +inq +connect
setmqaut -m VENUS -t queue -g bar -n 'BAR.**.RQST' -all +get 
setmqaut -m VENUS -t queue -g bar -n 'FOO.**.REPLY' -all +put

这时,Alice 的用户 ID 已经被赋予到 BAR.**.RQST 队列的 +get 和 +put(通过作为两个不同分组的成员)。其效果见 dspmqaut 命令的累计作用:

setmqaut -m VENUS -t queue -g foo -n 'BAR.**.RQST' -all +put 
setmqaut -m VENUS -t queue -g bar -n 'BAR.**.RQST' -all +get 

dspmqaut -m VENUS -t queue -n BAR.UPDATE.RQST -p alice 
Entity alice has the following authorizations for object 
BAR.UPDATE.RQST: 
	get 
	put

在以上示例中,在两个 setmqaut 命令中指定的配置文件是相同的:BAR.**.RQST。但是,用于为 FOO 队列授权的配置文件则不尽相同:

setmqaut -m VENUS -t queue -g foo -n 'FOO.**' -all +inq +get +browse 
setmqaut -m VENUS -t queue -g bar -n 'FOO.**.REPLY' -all +put

FOO.**.REPLY 配置文件要比 FOO.** 配置文件更加具体。但是,大多数特定配置文件的规则在这种情况下都不适用。由于两个配置文件位于两个不同的分组,因此它们实际上并未重叠。显而易见,从 dspmqaut 命令的结果可以看出这一点:

dspmqaut -m VENUS -t queue -n FOO.BAR.REPLY -g foo 
Entity foo has the following authorizations for object FOO.BAR.REPLY: 
	get 
	browse
	inq 
dspmqaut -m VENUS -t queue -n FOO.BAR.REPLY -g bar 
Entity bar has the following authorizations for object FOO.BAR.REPLY: 
	put
dspmqaut -m VENUS -t queue -n FOO.BAR.REPLY -p alice 
Entity alice has the following authorizations for object FOO.BAR.REPLY: 
	get 
	browse 
	put 
	inq

dmpmqaut 命令

上一个示例中使用的 dspmqaut 命令将根据所有适用配置文件来计算有效权限。虽然这极为有用,但在一些情况下会结合一些配置文件中的权限,从而造成意外结果,而造成授权失败的原因也不明显。幸运的是,针对这种情况也有一个命令可用:

dmpmqaut -m VENUS -t queue -n FOO.BAR.REPLY  -p alice -e
profile:     FOO.**.REPLY
object type: queue
entity:      bar
entity type: group
authority:   put
- - - - - - - -
profile:     FOO.**
object type: queue
entity:      foo
entity type: group
authority:   get browse inq

–e 选项的 dmpmqaut 命令将显示构成了某个实体的有效累计权限(针对对象)的所有配置文件。可以看到,Alice 的用户 ID 继承自赋予 Foo 和 Bar 分组的权限,并且各分组最具体的配置文件已应用于针对 FOO.BAR.REPLY 队列的累计有效权限。

调试授权问题

尽管您费尽心思,有时应用程序仍然会接收到 2035 Authorization Error 返回码。通常,这是没有为某个对象授权所致,而问题症结也可以很容易确定。比较棘手的情况是应用程序有正确的对象,但尝试使用未授权的提升权限,比如 +altuser 或 +passid。对于这种情况,最简单的诊断方法是启用授权事件。

如果您具备多年的 WebSphere MQ 使用经验,则提到授权事件可能会让您条件反射般地去找十六进制计算器。但这已经一去不复返!MS0P SupportPac 提供了一个 PCF 解码器插件,可简化事件消息的解析工作。事件消息会通知您造成调用失败的用户 ID、失败对象、针对该对象的 API 调用以及 API 调用中使用的操作。如果无法立即查明问题所在,您可以使用此信息结合 dmpmqaut 命令来查看所有相关配置文件(构成了对该用户及该对象的权限)的列表。

SupportPac MS0P 目前还包含一个可链接的 Object Authority Manager (OAM) 实现,可记录调用并将它们传递给本机 OAM。OAM 被设计为可插入的组件,可被替换或扩展,以替换或扩展本机功能。如果希望自己编写新的组件,则 MS0P 中的实现可以作为自定义实现的框架使用。如果这听起来很熟悉,那么您可能已经意识到这种功能在之前的 SupportPac MS07 中出现过。

融会贯通

显而易见,通过指定不同级别的通配符以及累计多个分组的权限,您可以构建非常细粒度的授权模式。我的建议是尽可能避免这一情况。复杂性和安全性是最大的敌人。应该始终选择最简单的方法来解决问题。事实上,我写了这么多文字的目的就是希望大家能够认识到,授权模式永远都不是完善的,除非已经简化到不能再简化为止。

还有一点需要指出,本文的目标是展示各组件之间如何形成一个整体,而不是简单地提供可应用的授权示例。这也是示例中未使用授权的原因所在。虽然它们使用与队列授权相同的语法以及相同的优先规则(为配置文件的简单性起见),但授权是在名称空间而非特定对象上运作的。这将是未来任务:消息传递 的主题。

我的另一个建议是,授权在执行之前不具效力。回想一下,授权执行您想做的,而验证首先将确定您的身份。与队列管理器建立连接时,无论是通过其他队列还是通过客户机通道,所需的验证级别都将由管理员来决定并进行配置。

请记住,没有 MCAUSER 集的任何入站通道都允许管理员访问队列管理器。如果非管理员实体可以使用所有管理权限进行连接或者冒充合法应用程序或用户的身份,则再完美的模式都是毫无用处的。请确保为所有入站通道建立了验证过程,然后再开始考虑授权模式。这还包括 SYSTEM.DEF.** 和 SYSTEM.AUTO** 通道。要确保授权模式得到正确的执行,通常需要在每一个入站通道中启用 SSL、安全退出或同时结合两者。

WebSphere MQ 安全性:实时!

今年我将在 IMPACT 2010 举办两场 WebSphere MQ 安全会议。第一场是基本管理强化会议,我将更加详细地讨论本文所提到的验证机制。 另一场会议是全新的 WebSphere MQ 安全实验,包括配置 SSL 和安全退出机制以提供验证,以及构建授权模式和诊断问题的动手实践。如果您今年将参加 IMPACT,请不要错过这两个会议,另外还请踊跃提问。我期待在拉斯维加斯与您相会!


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=497758
ArticleTitle=任务:消息: 理解 WebSphere MQ 授权和 setmqaut 命令
publish-date=06282010