更新开始

访问控制表

访问控制表(ACL)条目允许或拒绝用户访问对象。 不过,ACL 条目并不保护对象,因为 ACL 条目无法验证用户的身份。ACL 条目中包含用户名,并可指定主机名或域名。例如,用户有可能获权访问对象,方法是在主机名与授权的 Windows 域名相同的计算机上创建帐户。使用 ACL 条目可控制对代理域中对象的访问,但不要依靠 ACL 条目来保护您的代理域;使用 SSL 或安全出口可保护代理域中各组件之间的通道。

WebSphere Message Broker 使用访问控制表(ACL)条目来管理哪些用户和组可操作代理域中的对象。可授予用户或组四种不同的访问级别:完全控制、查看、部署和编辑。并非所有访问级别对所有对象类型都有效;请参阅 ACL 许可权,了解可应用于每一对象类型的权限列表,以及用户或组可执行的操作概述。

为了减少代理管理员必须创建的访问控制条目的数量,ACL 许可权进行分层操作。树的根处是 ConfigManangerProxy 对象,它有三个子代:RootTopic、Subscriptions 和 PubSubTopology。PubSubTopology 对象可以有零个或更多代理作为子代,并且每个代理可以有零个或更多执行组作为子代。ACL 条目添加到给定的对象后,该许可权则授予该对象以及层次结构中其下的所有对象,除非该条目被另一 ACL 条目覆盖。

z/OS 上,必须为用户标识和组定义 OMVS 段,以使配置管理器从外部安全性管理器(ESM)数据库获取用户标识和组信息。

下图是一个层次结构示例:

本图是一个层次结构示例。根目录为 CMP,其下包含三个子代:RootTopic、Subscriptions 和 PubSubTopology。PubSubTopology 包含两个子代:Broker1 和 Broker2。每个代理包含两个子代:Eg1A 和 Eg1B。

下列示例显示该层次结构行为在实践中如何工作。

示例 1

UserA 没有访问控制条目。因此,UserA 无法操作层次结构中的任何对象,或查看在层次结构中定义的任何对象。

示例 2

UserB 的 ACL 条目使他具有对执行组 Eg1A 的部署权。这也表示他对 PubSubTopology 和 Broker1 具有查看权。 UserB 必须能够查看 PubSubTopology 和 Broker1(例如 Message Brokers Toolkit 中),从而能够部署到 Eg1A。

由于 UserB 没有对应于 PubSubTopology 或 Broker1 的任何 ACL 条目,因此 UserB 不继承对层次结构中其他代理或执行组的访问权。实际上,这意味着 UserB 可以看到代理 Broker1 上定义了其他执行组,但无法看到任何详细信息(包括执行组的名称)。同理,UserB 可以看到拓扑中的其他代理,但无法看到详细信息。UserB 无权访问 RootTopic 或 Subscriptions(预订表)。

以下命令将为 UserB 创建 ACL 条目:
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1A
mqsilistaclentry 命令随后显示以下信息:
BIP1778I: userb -USER  -  D  -  Broker1/Eg1A      -  ExecutionGroup

示例 3

UserC 的一个 ACL 条目使她对配置管理器代理(CMP)具有查看权限,另一个 ACL 条目使她对 Broker1 具有完全控制权。这使她具有以下权限:

CMP 查看
RootTopic 查看
Subs 查看
Topology 查看
Broker1 完全控制
Eg1A 完全控制
Eg1B 完全控制
Broker2 查看
Eg2A 查看
Eg2B 查看

以下命令会为 UserC 创建 ACL 条目:
mqsicreateaclentry testcm -u UserC -a -x V -p
mqsicreateaclentry testcm -u UserC -a -x F -b Broker1
mqsilistaclentry 命令随后显示以下信息:
BIP1778I: userc                -  USER  -  V  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userc                -  USER  -  F  -  Broker1              -  Broker

示例 4

UserD 的一个 ACL 条目使他对 CMP 具有完全控制权,另一个 ACL 条目使他对 Broker1 具有查看权。由于授予 UserD 对 Broker1 的查看权,UserD 不继承完全控制权。这样使用查看 ACL 条目是有用的,因为它允许通常对给定对象具有完全控制权的用户暂时减少自己的访问权,以防止意外删除或部署。如果用户需要对象的完全控制权,除去查看条目时会恢复完全控制权,这样他们就可以执行所需的操作,然后恢复查看条目。UserD 具有以下权限:

CMP 完全控制
RootTopic 完全控制
Subs 完全控制
Topology 完全控制
Broker1 查看
Eg1A 查看
Eg1B 查看
Broker2 完全控制
Eg2A 完全控制
Eg2B 完全控制

以下命令会为 UserD 创建 ACL 条目:
mqsicreateaclentry testcm -u UserD -a -x F -p
mqsicreateaclentry testcm -u UserD -a -x V -b Broker1
mqsilistaclentry 命令随后显示以下信息:
BIP1778I: userd                -  USER  -  F  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userd                -  USER  -  V  -  Broker1              -  Broker
以下命令随后可为 UserD 删除 ACL 条目:
mqsideleteaclentry testcm -u UserD -a -b Broker1

要更改对象的访问控制条目,用户必须对该对象或层次结构中的任何父代具有完全控制权。这意味着,更改 ACL 本身的许可权与上面所述的相同,但将较低的许可权授予树目录结构中层次较低的子代时不能除去对 ACL 的访问权;这一点很有必要,因为否则用户将能够赋予自身查看条目,却不能再除去它。

可以使用 Java 配置管理器代理 API 或 mqsicreateaclentrymqsideleteaclentrymqsilistaclentry 命令处理 ACL 条目。

相关概念
访问运行时资源的权限
在 z/OS 上启用配置管理器以获取用户标识信息
基于主题的安全性
相关任务
设置代理域安全性
启用基于主题的安全性
取消正在进行中的部署
添加新主题
相关参考
mqsicreateaclentry 命令
mqsideleteaclentry 命令
mqsilistaclentry 命令
ACL 许可权
声明 | 商标 | 下载 | 书库 | 支持 | 反馈
Copyright IBM Corporation 1999, 2006 最后一次更新时间:2006/08/14
ap01380_


更新结束