WebSphere Event Broker 使用访问控制表(ACL)来管理哪些用户和组可在配置管理器和 Message Brokers Toolkit中操作对象。可授予用户或组“完全控制”、“查看”、“部署”和“编辑”这四种不同的访问级别。不是所有的访问级别对所有对象类型都有效;下表描述了可为每个对象类型应用哪些许可权,并总结了用户或组可执行的操作。
为了减少代理管理员必须创建的访问控制条目的数量,ACL 许可权进行分层操作。树形目录的根为 ConfigManangerProxy 对象,它具有三个子代:RootTopic、Subscriptions 和 PubSubTopology。PubSubTopology 对象可以有零个或更多代理作为子代,并且每个代理可以有零个或更多执行组作为子代。当 ACL 条目添加到给定的对象时,该对象及层次结构中其下的所有对象都被授予许可权,除非该对象被其他 ACL 条目覆盖。
您必须在 z/OS 上为用户标识和组定义 OVMS 数据库,以便配置管理器从外部安全性管理器(ESM)数据库中获取用户标识和组信息。
下图是一个层次结构示例:
以下方案说明了该层次结构情况在实践中如何工作。
方案 1
UserA 没有访问控制条目。因此,UserA 无法操作层次结构中的任何对象,或查看在层次结构中定义的任何对象。
方案 2
CMP 无
RootTopic 无
Subs 无
Topology 查看
Broker1 查看
Eg1A 部署
Eg1B 无
Broker2 无
Eg2A 无
Eg2B 无
注:因为已将访问控制条目给予了执行组,该条目具有了对父代理和拓扑的隐式查看许可权,否则它将不会显示在工具中。但是,由于该用户没有实际的代理或拓扑的 ACL 条目,因此没有对其他代理或执行组的继承访问权。实际上,这意味着 UserB 可以看到代理上定义的其他执行组,但无法看到任何详细信息(包括名称)。
同理,UserB 可以看到拓扑中的其他代理,但无法看到详细信息。UserB 没有对 RootTopic 或 Subscriptions 表的访问权。
方案 3
CMP 查看
RootTopic 查看
Subs 查看
Topology 查看
Broker1 完全控制
Eg1A 完全控制
Eg1B 完全控制
Broker2 查看
Eg2A 查看
Eg2B 查看
方案 4
CMP 完全控制
RootTopic 完全控制
Subs 完全控制
Topology 完全控制
Broker1 查看
Eg1A 查看
Eg1B 查看
Broker2 完全控制
Eg2A 完全控制
Eg2B 完全控制
请注意,在该示例中,如果用户没有 Broker1 的查看条目,他将具有完全控制权。在此使用查看条目是非常有用的,因为它允许通常对给定对象具有完全控制访问权的用户暂时减少自己的访问权,以便防止发生意外删除或部署。如果用户需要对象的完全控制权,则将查看条目除去会恢复完全控制权,这样他们就可以执行所需的操作,然后再恢复查看条目。
为了更改对象的访问控制条目,用户必须对层次结构中的对象或任何父具有完全控制权。这意味着对 ACL 本身进行更改所需的许可权与以上描述的相同,但是如果将较低的许可权授予树目录结构中层次较低的子代不能除去对 ACL 的访问权;这一点很有必要,因为否则的话,用户将可以给予他们自己查看条目,却无法再除去它。
可以使用 Java 配置管理器代理 API 或 mqsicreateaclentry、mqsideleteaclentry 和 mqsilistaclentry 命令处理 ACL 条目。
对象 | 许可权 | 权限 |
---|---|---|
拓扑 | 完全控制 |
|
查看 |
|
|
代理 | 完全控制 |
|
部署 |
|
|
查看 |
|
|
执行组 | 完全控制 |
|
部署 |
|
|
查看 |
|
|
根主题 | 完全控制 |
|
部署 |
|
|
编辑 |
|
|
查看 |
|
|
预订 | 完全控制 |
|
查看 |
|