Sun Java System Message Queue 3.7 UR1 管理指南

用户授权：访问控制属性文件

访问控制属性文件（ACL 文件）包含一些规则，用来指定用户和用户组可以执行的操作。您可以编辑 ACL 文件，将操作限定给某些用户和组。各个代理实例可以使用不同的 ACL 文件。

无论用户信息是放在平面文件用户系统信息库中还是放在 LDAP 用户系统信息库中，都会使用 ACL 文件。当客户端应用程序执行以下操作之一时，代理将会检查其 ACL 文件：

创建连接
创建生成方
创建使用方
浏览队列

代理将检查 ACL 文件，以确定是授权生成请求的用户还是用户所属的组来执行该操作。

如果对 ACL 文件进行编辑，新的设置将在下一次代理检查该文件以验证授权时生效。编辑完文件后，不需要重新启动代理。

创建访问控制属性文件

ACL 文件是特定于实例的。每次启动代理实例时，都会在该实例目录中创建一个名为 accesscontrol.properties 的默认文件。该文件的路径为如下格式（请参见附录 A， Message Queue^TM 数据在特定平台上的位置）：

…/instances/brokerInstanceName/etc/accesscontrol.properties

ACL 文件的格式与 Java 属性文件类似。首先定义文件的版本，然后指定访问控制规则，规则分为三部分：

连接访问控制
物理目的地访问控制
物理目的地自动创建访问控制

version 属性定义 ACL 属性文件的版本，不能更改此条目。

version=JMQFileAccessControlModel/100

下面说明访问规则的基本语法并介绍如何计算权限，然后介绍指定访问控制的 ACL 文件的三个组成部分。

访问规则语法

ACL 属性文件中，访问控制用于定义特定用户或组对受保护的资源（如物理目的地和连接服务）具有哪些访问权限。访问控制由一个规则或一组规则组成，每个规则都由一个 Java 属性表示：

这些规则的基本语法如下：

resourceType.resourceVariant

.operation.access.
principalType=principals

表 7–3 介绍了语法规则的元素。

表 7–3 访问规则的语法元素


元素	描述
`resourceType`	以下选项之一：`connection`、`queue` 或 `topic`。
`resourceVariant`	`resourceType` 指定的类型的一个实例。例如，`myQueue`。通配符 (*) 可用于表示所有连接服务类型或所有物理目的地。
`operation`	值取决于所设置的访问规则的类型。
`access`	以下选项之一：`allow` 或 `deny`。
`principalType`	以下选项之一：`user` 或 `group`。有关详细信息，请参见组。
`principals`	可能具有规则左侧指定的访问权限的人。如果 `principalType` 为 `user`，则可能是单个用户或以逗号分隔的用户列表；如果 `principalType` 为 `group`，则可能是单个组或以逗号分隔的组列表。通配符 (*) 可用于表示所有用户或所有组。

下面是一些访问规则示例：

以下规则表示所有用户都可以向名为 q1 的队列发送消息。
```
queue.q1.produce.allow.user=*
```
以下规则表示任何用户都可以向任何队列发送消息。
```
queue.*.produce.allow.user=*
```

注 –

要指定非 ASCII 的用户、组或目的地名称，请使用 Unicode 转义符 (\\uXXXX) 表示法。如果在您编辑并保存的 ACL 文件中，这些名称采用了非 ASCII 编码，则可以通过 Java native2ascii 工具将此文件转换为 ASCII。有关更多详细信息，请参见

http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

权限的计算方式

当文件中存在多个访问规则时，将按如下方式计算权限：

具体的访问规则将覆盖一般访问规则。应用以下两条规则之后，所有用户都可以向所有队列发送消息，但是 Bob 不能向 tq1 发送消息。
```
queue.*.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
指定给明确 principal 的访问权限将覆盖指定给 * principal 的访问权限。以下规则将拒绝 Bob 向 tq1 发送消息，但允许其他人发送。
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.user=Bob
```
用户的 * principal 规则将覆盖组的对应 * principal 规则。例如，以下两条规则将允许所有通过验证的用户向 tq1 发送消息。
```
queue.tq1.produce.allow.user=*
queue.tq1.produce.deny.group=*
```
授予用户的访问权限将覆盖授予用户所属组的访问权限。在以下示例中，即使 Bob 是 User 的成员，他也不能生成发送到 tq1 的消息。User 的其他所有成员都可以生成此类消息。
```
queue.tq1.produce.allow.group=User
queue.tq1.produce.deny.user=Bob
```
任何未通过访问规则明确授予的访问权限均默认为被拒绝。例如，如果 ACL 文件不包含任何访问规则，则所有用户的所有操作都将被拒绝。
如果同时允许和拒绝同一个用户或组的访问权限，则访问权限将相互抵消。例如，以下两条规则将使 Bob 无法浏览 q1：
```
queue.q1.browse.allow.user=Bob
queue.q1.browse.deny.user=Bob
```
以下两条规则将阻止 User 组使用 q5 中的消息。
```
queue.q5.consume.allow.group=User
queue.q5.consume.deny.group=User
```
如果多条规则等号左侧的内容都相同，则只有最后一条规则起作用。

用于连接服务的访问控制

ACL 属性文件中的连接访问控制部分包含代理连接服务的访问控制规则。连接访问控制规则的语法如下：

connection.resourceVariant.
access.principalType=
principals

为 resourceVariant 定义了两个值：NORMAL 和 ADMIN。这些预定义的值是您唯一能够授予访问权限的连接服务类型。

默认的 ACL 属性文件授予所有用户访问 NORMAL 连接服务的权限，并授予 admin 组中的用户访问 ADMIN 连接服务的权限：

connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admin

如果您使用的是基于文件的用户系统信息库，则默认组 admin 由用户管理器实用程序创建。如果您使用的是 LDAP 用户系统信息库，则可以通过执行以下操作之一来使用默认 ACL 属性文件：

在 LDAP 目录中定义一个名为 admin 的组。
使用在 LDAP 目录中定义的一个或多个组的名称来替换 ACL 属性文件中的名称 admin。

您可以对连接访问权限加以限定。例如，以下规则拒绝 Bob 访问 NORMAL，但允许其他人访问：

connection.NORMAL.deny.user=Bob
connection.NORMAL.allow.user=*

可以使用星号 (*) 指定所有通过验证的用户或组。

使用 ACL 属性文件来授权访问 ADMIN 连接的方式与使用基于文件的用户系统信息库和 LDAP 用户系统信息库不同，如下所示：

基于文件的用户系统信息库
- 如果禁用访问控制，admin 组中的用户将具有 ADMIN 连接权限。
- 如果启用访问控制，请编辑 ACL 文件。明确授予用户或组访问 ADMIN 连接服务的权限。

LDAP 用户系统信息库。如果您使用的是 LDAP 用户系统信息库，请执行下列所有操作：
- 启用访问控制。
- 编辑 ACL 文件并提供可以建立 ADMIN 连接的用户或组的名称。指定在 LDAP 目录服务器中定义的任何用户或组。

对物理目的地的访问控制

访问控制属性文件的目的地访问控制部分包含基于物理目的地的访问控制规则。这些规则决定谁（用户/组）可以在哪里（物理目的地）执行什么（操作）。这些规则控制的访问类型包括向队列发送消息、向主题发布消息、从队列接收消息、订阅主题以及浏览队列中的消息。

默认情况下，任何用户或组都可以对任何物理目的地进行任意类型的访问。您可以添加更多特定的目的地访问规则或编辑默认的规则。本节的余下部分介绍物理目的地访问规则的语法，您必须理解这些语法才能编写自己的规则。

目的地规则的语法如下：

resourceType.resourceVariant.operation.access.principalType=principals

表 7–4 介绍了这些元素：

表 7–4 物理目的地访问控制规则的元素


组件	描述
`resourceType`	可以是 `queue` 或 `topic`。
`resourceVariant`	某个物理目的地名或所有物理目的地 (*)，星号表示所有队列或所有主题。
`operation`	可以是 `produce`、`consume` 或 `browse`。
`access`	可以是 `allow` 或 `deny`。
`principalType`	可以是 `user` 或 `group`。

可以将访问权限授予一个或多个用户和/或组。

以下示例说明了不同类型的物理目的地访问控制规则：

允许所有用户向任意 queue 目的地发送消息。
```
queue.*.produce.allow.user=*
```
拒绝 user 组的任何成员订阅 Admissions 主题的能力。
```
topic.Admissions.consume.deny.group=user
```

对自动创建的物理目的地的访问控制

ACL 属性文件最后一部分所包括的访问规则指定代理将为哪些用户和组自动创建物理目的地。

当用户在尚不存在的物理目的地上创建生成方或使用方时，如果已启用代理的自动创建属性，则代理将会创建该目的地。

默认情况下，任何用户或组都有权让代理为其自动创建一个物理目的地。此权限由以下规则指定：

queue.create.allow.user=*
topic.create.allow.user=*

您可以编辑 ACL 文件以限制此类访问权限。

物理目的地自动创建访问规则的一般语法如下：

resourceType.create.access.principalType=principals

其中 resourceType 为 queue 或 topic。

例如，以下规则允许代理为除 Snoopy 之外的每个用户自动创建 topic 目的地。

topic.create.allow.user=*
topic.create.deny.user=Snoopy

请注意，物理目的地自动创建规则的效果必须与物理目的地访问规则的效果一致。例如，如果您 1) 更改目的地访问规则，禁止任何用户向目的地发送消息；但是 2) 启用了目的地的自动创建，那么如果目的地不存在，代理将创建一个物理目的地，但不会向该目的地发送任何消息。