映射 ACL

为了确保只有有权访问某项的用户才能在 搜索结果中，您应使用访问控制列表 (ACL) 将各项编入索引 从企业代码库中获取您必须为代码库的 ACL 建模，并且 在将存储库中的项编入索引时，添加这些 ACL。内容连接器 SDK 提供了一组丰富的 ACL 方法，足以为 大多数代码库中。

注意 ：内容连接器 SDK 支持单网域 ACL，但不支持 实现跨网域访问控制您无法向您的组织外部的任何用户和群组授予访问权限。任何引用了外部用户或群组的 ACL 不会产生任何影响。

创建 ACL

创建 ACL 的过程分为两个步骤：

1. 创建 Principal 使用 ACL 类。
2. 使用 Acl.Builder 类使用主账号构建 ACL。

本文档的其余部分将介绍构建模型时需要了解的一些概念， 并创建 ACL，例如继承和包含。

使用外部 ID 创建主账号

Google Cloud Search 要求将用户和群组解析为 Google 电子邮件地址。将代码库项编入索引时，内容连接器可能没有这些电子邮件地址。不过，通过内容连接器 SDK，您可以使用 外部 ID（向用户或群组授予对代码库项的访问权限的 ID）， 电子邮件地址的一部分，以便将项编入索引。使用 getUserPrincipal() 方法或 getGroupPrincpal() 方法创建包含外部 ID 的主账号。还有一些 静态方法（位于 ACL 用于构建 Principal 对象。

注意 ：在用户使用外部 ID 之前，不会在搜索结果中看到内容 已与其 Google 账号同步。您可以使用身份连接器让这些外部用户 ID 或群组 ID 与 Google 电子邮件地址保持同步。如需了解有关身份连接器的更多信息，请参阅 创建身份连接器。

警告 ：将内容的身份重新映射到其他身份后，您必须 将内容重新编入索引，以使新身份生效。如需了解详情，请参阅 再到重新映射身份。

ACL 继承

ACL 继承关系是指对特定内容和特定内容进行授权 将根据项的 ACL 和 其继承链的 ACL。用于做出授权决策的规则 取决于代码库和项的属性

设置继承

每项内容可以具有“直接允许的主账号”和“直接拒绝的主账号”， 使用 setReaders() 和 setDeniedReaders() 方法。“直接允许的主账号”是指在 ACL 中标识为能够直接访问特定项的用户。“直接拒绝的主账号”是指在 ACL 中标识为无权访问特定项的用户。

一项内容还可以沿用“间接允许的主账号”以及 使用 setInheritFrom() 方法。“间接允许的主账号”是指能够通过 ACL 继承来间接访问特定项的用户。“间接拒绝的主账号”是指被拒绝通过 ACL 继承来访问特定项的用户。

注意 ：如果您使用 setInheritFrom() 方法，您必须使用 setInheritanceType() 方法。如需了解有关继承类型的信息，请参阅 设置继承类型。

图 1 显示了 setInheritFrom() 方法用于继承间接允许和间接拒绝的主账号。

图 1. setInheritFrom() 方法。

图 1 表示了以下访问控制：

• 用户 1 是项 A 的“直接允许的主账号”。
• 用户 2 是项 B 的“直接允许的主账号”。
• 项 B 继承项 A 的 ACL。

根据访问控制，访问规则如下：

• 用户 1 无需明确指定为项 B 的主账号即可成为项 B 的“间接允许的主账号”；用户 1 会继承访问权限，因为其被列为项 A 的“直接允许的主账号”，而项 B 则从项 A 继承其 ACL。
• 用户 2 不是项 A 的“间接允许的主账号”。

设置继承类型

如果您使用 setInheritFrom() 方法，则必须使用 setInheritanceType() 方法。继承类型决定了子节点的 ACL 与其父项的 ACL 合并。Acl.InheritanceType 实现了三种继承类型：

• BOTH_PERMIT - 如果将继承类型设置为 BOTH_PERMIT，则只有在子项的 ACL 和父项的继承项 ACL 都允许某个用户访问该项时，系统才会授予该用户对该项的访问权限。

• CHILD_OVERRIDE - 将继承类型设置为 CHILD_OVERRIDE 以强制子项 项的 ACL，当继承父项的 ACL 时，将优先于继承的父项的 ACL 冲突。因此，当父项的 ACL 拒绝用户以被拒读取者身份进行访问时，如果用户能够以读取者身份访问子项，则用户仍然可以进行访问。相反，如果用户是子项的被拒读取者，则即使父项的 ACL 授予用户访问权限，用户也无法进行访问。

• PARENT_OVERRIDE - 将继承类型设置为 PARENT_OVERRIDE 以强制 当父项的 ACL 时，将优先于子项的 ACL 冲突。因此，当子项的 ACL 拒绝用户以被拒读取者身份进行访问时，如果用户能够以读取者身份访问父项，则用户仍然可以进行访问。相反，如果用户是父项的被拒读取者，则即使子项的 ACL 授予用户访问权限，用户也无法进行访问。

在评估 ACL 继承链时，授权决策的结果可能会因评估的顺序而发生变化。Cloud Search 提供从叶到根的 ACL 继承链的评估顺序。具体而言，ACL 决策 则从对子项及其父项进行评估开始， 一直到根父项。

例如，如果子发布商的继承类型为 CHILD_OVERRIDE，并且用户 那么云端硬盘便无需评估父级。 不过，如果子发布商拥有 PARENT_OVERRIDE 或 BOTH_PERMIT，则云端硬盘会继续运行 以及评估链中更深层的继承情况。

删除包含关系和项

将某项内容编入索引时，您可以使用 setContainer() 方法 IndexingItemBuilder 类。容器与容器之间的关系决定了 项的层次结构，并确保项得到正确删除。 当容器被删除时，它所包含的项也会被删除。

包含关系完全独立于 ACL 继承规则。 例如，文件系统中的某个文件可以包含在 但从其他文件夹继承 ACL。删除某个文件夹时，系统不会删除继承其 ACL 的项，除非这些项也在该文件夹的包含层次结构中。

图 2 表示了以下访问控制关系：

• 用户 1 是项 A 的“直接允许的主账号”。
• 用户 2 是项 B 的“直接允许的主账号”。
• 用户 3 是项 C 的“直接允许的主账号”。
• 项 C 继承项 A 的 ACL。
• 项 B 指定项 A 作为其容器。
• 项 C 指定项 B 作为其容器。

根据访问控制，访问规则如下：

• 间接访问来自于setInheritFrom() 方法。因此，用户 1 可以访问项 C，因为项 C 继承了项 A 的 ACL。
• 间接访问不是通过项 B 包含的项 C 进行的。因此，用户 2 无法访问项 C。

。 <ph type="x-smartling-placeholder">

</ph>

图 2.正在使用的 setInheritFrom() 方法。

ACL 继承与包含层次结构分离后，您就可以对 许多不同的现有结构。

成功删除项以后的情况如下：

• 包含被删除项的任何项都将无法搜索，并且系统会安排从 Google 的数据源将其删除。
• 已使用 setInheritFrom() 方法 都无法搜索到

如果资源有一个使用 setInheritFrom() 方法，但它没有使用 setContainer() 或其包含层次结构不包含已删除的内容，该内容及其数据 仍然保留在 Google 的数据源中。您将负责删除该项。

图 3 显示了删除操作在项的层次结构中的工作方式。

图 3. 删除项和 ACL 继承。

图 3 表示了以下访问控制关系：

• 用户 1 是项 A 的“直接允许的主账号”。
• 用户 2 是项 D 的“直接允许的主账号”。
• 项 D 和项 E 都继承了项 A 的 ACL。
• 项 D 指定项 A 作为其容器。
• 项 A 和项 E 是根级项，因为它们没有容器项。

删除操作通过容器引用进行级联。删除项 A 以后的情况如下：

• setInheritFrom() 的所有后代 所有用户都无法再访问该参考文件。
• 任何用户都无法访问项 A。
• 系统会隐式删除项 D。任何用户都无法访问项 D。
• 系统不会删除项 E，因为删除操作仅通过容器引用进行级联。
• 将无法访问项 E，并且任何用户都无法搜索项 E。