ACL 的作用方式
一个访问控制规则中定义的参与者权限可能与其他规则中定义的其他权限发生冲突。例如，您可以定义一个访问控制规则，为 Team 1 组中的每个人赋予权限，使他们可以删除“正在审阅”状态下属于 /Acme 域的所有事件报告。然而，在另一个访问控制规则中，您可以明确拒绝用户 Audrey.Carmen 具有该权限，尽管她是 Team 1 组中的成员。在这种情况下，ACL 机制将为参与者计算实际权限。
下表中提供了有关权限进行协同工作的方式的快速参考。可在表下方获取完整的说明。
 | 计算 ACL 时，将忽略拒绝虚拟角色 OWNER 的权限的访问控制规则。 |
应基于以下规则计算一位参与者的实际权限：
• 每个参与者 (用户、用户定义的组、系统组或组织) 都最多具有一个赋予 ACL 条目，一个拒绝 ACL 条目和一个绝对拒绝 ACL 条目，即，对任何参与者都不允许有多个相同权限类型的 ACL 条目。每个条目指定将被赋予、拒绝或绝对拒绝的权限集。虚拟角色最多可拥有一个赋予 ACL 条目和一个拒绝 ACL 条目。不能为虚拟角色指定绝对拒绝权限。
| | 在生成 ACL 之前，动态角色会解析成为特定系统组。请参阅解析规则中的动态角色时的注意事项。 |
• 会将对除特定参与者之外的所有参与者准予、拒绝或绝对拒绝的权限视为针对某组指定的权限，其组中成员包括除“管理员”用户、选定的用户或选定的组、动态角色或组织中的用户外的所有用户。
• 如果某个特定用户、组、虚拟角色或组织没有 ACL 条目，则该参与者设置为空权限。实际上，权限设置为空将拒绝参与者对对象的访问权限。
• 如果同时存在赋予参与者权限的赋予条目和拒绝参与者使用相同权限的拒绝或绝对拒绝条目，则不赋予该权限。
• 明确赋予 (+) 虚拟角色 OWNER 的权限，覆盖通过单个用户或用户所属组或组织的拒绝条目拒绝赋予 (-) 用户 (该用户是可拥有对象的所有者) 的任何权限。
• 明确赋予 (+) 虚拟角色 OWNER 的权限，不覆盖通过单个用户或用户所属组或组织的绝对拒绝条目绝对拒绝赋予 (!) 用户 (该用户是可拥有对象的所有者) 的任何权限。
• 拒绝赋予 (-) 虚拟角色 OWNER 的任何权限不覆盖明确赋予 (+) 用户 (该用户是可拥有对象的所有者) 或用户所属组或组织的权限。拒绝虚拟角色 OWNER 的权限会遭到忽略。
• 对单个用户明确赋予 (+) 的权限覆盖对用户的组或组织拒绝 (-) 的权限以及对虚拟角色 ALL 拒绝的权限。例如，用户 ReneN 是 Group 1 的成员根据对 Acme 域的访问控制规则，拒绝 Group 1 的所有成员对处于“正在审阅”生命周期状态的事件报告的修改权限。但是，如果另一个访问规则明确地授予 ReneN 使用修改事件报告的权限，则尽管 ReneN 是 Group 1 中的成员，他却不具有“修改”权限。
• 对用户的绝对拒绝 (!) 或拒绝 (-) 权限覆盖对该用户所在组或所在组织赋予 (+) 的权限。例如，根据对 Acme 域的访问控制规则，赋予 Group 1 的所有成员对处于“已审阅”生命周期状态的更改通告的“修改”权限。另一个访问规则拒绝 ReneN 对更改通告的“修改”权限。尽管 ReneN 是 Group 1 的成员，但是 ReneN 不具有“修改”权限。
• 对单个用户明确赋予 (+) 的权限不能覆盖对其所在组或所在组织绝对拒绝 (!) 的权限。例如，根据对 Acme 域的访问控制规则，绝对拒绝 Group 1 的所有成员对处于“已完成”生命周期状态的更改请求的管理权限。即使另一个访问控制规则明确赋予 ReneN 管理更改请求的权限，也同样拒绝 ReneN 的管理权限。
• 对于给定的用户，实际的组授予权限集是该用户所属各组和组织中所有授予权限的并集。其中包括赋予虚拟角色 ALL 的权限。例如，如果用户 ReneN 同时属于 Group 1、Group 2 和 Group 3，则 ReneN 的授予组权限集将包括赋予这三个组的全部权限。
• 对于给定的用户，实际的组拒绝权限集是该用户所属各组和组织中所有拒绝权限 (-) 的并集。其中包括拒绝赋予虚拟角色 ALL 的权限。例如，如果用户 ReneN 同时属于 Group 1、Group 2 和 Group 3，则 ReneN 的拒绝组权限集将包括拒绝赋予这三个组的全部权限。
• 对于给定的用户，实际的组绝对拒绝权限集是该用户所属各组和组织中所有绝对拒绝权限 (!) 的并集。例如，如果用户 ReneN 同时属于 Group 1、Group 2 和 Group 3，则 ReneN 的拒绝组权限集将包括拒绝这三个组的全部权限。无法绝对拒绝虚拟角色 ALL 的权限。
当为 ACL 计算权限时，将合并用户 ReneN 的准予、拒绝和绝对拒绝权限集来确定访问权限。例如，作为 Group 1 的成员，ReneN 被赋予了读取在 /Acme 域中“正在审阅”生命周期状态下所有事件报告。然而，ReneN 还是 Group 2 的成员，这些成员在该域中被拒绝读取事件报告。计算时，对于 /Acme 域，ReneN 读取事件报告的权限设置为空，因此拒绝 ReneN 的访问。
下表提供了一些计算权限的更加深入的示例。假定您是管理员，正在为多个域创建访问控制策略。Ann 是您指定的其中一个用户，属于组 G1，但不属于组 G2。如果按表中所示分配权限，则最后一列将标明 Ann 的最终权限。
G1 权限 | 全部 (G2 除外) 权限 | G1 和全部 (G2 除外) 的并集 | 单独权限 | 最终权限 | |
|---|---|---|---|---|---|
+ - ! | 修改 (M) 空集 空集 | 创建 (C) 空集 空集 | (C)+(M) 空集 空集 | 删除 (D) + 管理 (A) 空集 空集 | (C) + (M) + (D) + (A) |
+ - ! | (M) (D) (A) | (C) (M) 空集 | (C)+(M) (D) + (M) (A) | (D) 空集 空集 | (C)+(D) |
+ - ! | (M) + (A) (D) 空集 | (D) (C) 空集 | (M) + (A) + (D) (C)+(D) 空集 | (C) (M) (A) | (C) |
+ - ! | (M) 空集 空集 | (C) 空集 (A) | (M)+(C) 空集 (A) | (D) + (A) (M) 空集 | (C)+(D) |
定义了域的访问控制规则后，所有属于您已为其创建了规则的同一个域的、处于特定状态的对象类型的实例将共享一个 ACL。此后将保存 ACL 与对象类型、状态和域之间的这种关联。参与者试图访问对象 (例如，查看或修改对象) 时，将检索关联的 ACL 并实施该策略。ACL 计算后将被缓存，以便在下次请求访问时可对其进行快速检索。
例如，假定在 /Acme 域内，用户 Audrey.Carmen 是某个组的成员，该组成员具有读取和删除处于“已关闭”状态下类型为 WTObject 的所有对象的权限。她还是另一个组的成员，该组具有修改 /Acme/Support 域内处于“已关闭”状态的所有事件报告的权限，其中 IncidentReport 是 WTObject 的子类型。但是，对于作为单个用户的 Audrey.Carmen，在 /Acme 域内存在另一个访问控制规则，该规则明确地拒绝她删除“已关闭”状态下的事件报告的权限。
下面显示了 Audrey.Carmen 的 ACL 条目，该条目与 /Acme/Support 域内“已关闭”状态下的事件报告关联：
Audrey.Carmen +读取、+修改、-删除
当 ACL 条目来自于对 /、/Acme 和 /Acme/Support 域的访问控制策略时，会赋予 Audrey.Carmen“读取和修改”权限。因为 IncidentReport 是 WTObject 的子类型，故 Audrey 对 WTObject 类型对象的读取和删除权限也将应用于事件报告。但是，因为存在另一个访问控制规则，该规则明确拒绝她对于“已关闭”状态下的事件报告的“删除”权限，她的最终权限是“读取和修改”，因此她不能删除属于 /Acme/Support 域的该类型和状态组合的对象。