根据用户上下文进行筛选

您可以根据用户或其群组对文档的访问权限来筛选用户的搜索结果。您可以使用用户令牌、用户 ID 或用户属性来筛选文档。 Amazon Kendra 也可以将用户映射到他们的群组。您可以选择 AWS IAM Identity Center 用作您的身份存储/来源。

用户上下文筛选是一种个性化搜索，其优点是控制对文档的访问权限。例如，并非所有在公司门户网站上搜索信息的团队都应该访问绝密的公司文档，这些文档也不应与所有用户相关。只有获得绝密文档访问权限的特定用户或团队组才能在搜索结果中看到这些文档。

将文档编入索引后 Amazon Kendra，会为大多数文档提取相应的访问控制列表 (ACL)。ACL 指定允许或拒绝哪些用户名和组名访问文档。没有 ACL 的文档是公共文档。

Amazon Kendra 可以为大多数数据源提取与每个文档关联的用户或群组信息。例如，Quip 中的文档可以包含有权访问该文档的精选用户的“共享”列表。如果您使用 S3 存储桶作为数据来源，则需要为 ACL 提供一个 JSON 文件，并将该文件的 S3 路径作为数据来源配置的一部分。如果将文档直接添加到索引，则可以在 Princip al 对象中指定 ACL 作为 BatchPutDocumentAPI 中文档对象的一部分。

您可以使用 CreateAccessControlConfigurationAPI 重新配置现有的文档级别访问控制，而无需再次为所有文档编制索引。例如，您的索引包含只有特定员工或用户才能访问的绝密公司文档。其中一位用户离开公司或转到应被禁止访问绝密文档的团队。用户仍然可以访问绝密文档，因为在您的文档之前被编入索引时，该用户拥有访问权限。您可以为具有拒绝访问权限的用户创建特定的访问控制配置。您可以稍后更新访问控制配置，以便在用户返回公司并重新加入“绝密”团队时允许访问。随着情况的变化，您可以重新配置文档的访问控制。

要将您的访问控制配置应用于某些文档，请使用 D oc ument 对象中AccessControlConfigurationId包含的 BatchPutDocumentAPI。如果您使用 S3 存储桶作为数据源，则.metadata.json使用更新AccessControlConfigurationId并同步您的数据源。 Amazon Kendra 目前仅支持对使用 BatchPutDocument API 编制索引的 S3 数据源和文档进行访问控制配置。

按用户令牌筛选

查询索引时，您可以使用用户令牌根据用户或其群组对文档的访问权限筛选搜索结果。当您发出查询时， Amazon Kendra 提取并验证令牌，提取和检查用户和群组信息，然后运行查询。将返回用户有权访问的所有文档，包括公共文档。有关更多信息，请参阅基于角色的访问控制。

您在UserContext对象中提供用户令牌，然后在查询 API 中传递该令牌。

以下命令说明如何添加用户令牌。

response = kendra.query(
    QueryText = query,
    IndexId = index,
    UserToken = {
        Token = "token"
    })

您可以将用户映射到群组。使用用户上下文筛选时，无需在发出查询时包含用户所属的所有群组。使用 PutPrincipalMappingAPI，您可以将用户映射到他们的群组。如果您不想使用 PutPrincipalMapping API，则必须在发出查询时提供用户名和该用户所属的所有群组。您还可以使用UserGroupResolutionConfiguration对象获取 IAM Identity Center 身份源中群组和用户的访问级别。

按用户 ID 和群组筛选

查询索引时，您可以使用用户 ID 和群组，根据用户或其群组对文档的访问权限筛选搜索结果。当您发出查询时， Amazon Kendra 会检查用户和群组信息并运行查询。将返回与用户有权访问的查询相关的所有文档，包括公共文档。

您还可以按用户和群组有权访问的数据来源筛选搜索结果。如果一个组与多个数据来源相关联，但您只想让该组访问特定数据来源的文档，则指定数据来源非常有用。例如，“研究”、“工程”和“销售和营销”这三个组都与存储在数据来源Confluence和Salesforce中的公司文档相关联。但是，“销售和营销”团队只需要访问存储在Salesforce中的客户相关文档即可。因此，当销售和营销用户搜索与客户相关的文档时，他们可以在搜索结果中看到来自 Salesforce 的文档。不从事销售和市场营销工作的用户不会在搜索结果中看到 Salesforce 文档。

您在UserContext对象中提供用户、群组和数据源信息，然后在 Query API 中传递这些信息。用户 ID 以及组和数据来源列表应与您在 Princip al 对象中指定的名称相匹配，以标识用户、组和数据来源。使用该Principal对象，您可以将用户、组或数据来源添加到允许列表或拒绝列表中以访问文档。

您必须提供以下任一信息：

• 用户和群组信息，以及（可选）数据来源信息。

• 仅当您使用 PutPrincipalMappingAPI 将用户映射到群组和数据源时，才会显示用户信息。您还可以使用UserGroupResolutionConfiguration对象获取 IAM Identity Center 身份源中群组和用户的访问级别。

如果查询中未包含此信息，则 Amazon Kendra 返回所有文档。如果您提供此信息，则仅返回具有匹配用户 ID、群组和数据来源的文档。

以下内容显示了如何包括用户 ID、群组和数据来源。

response = kendra.query(
    QueryText = query,
    IndexId = index,
    UserId = {
        UserId = "user1"
    },
    Groups = {
        Groups = ["Sales and Marketing"]
    },
    DataSourceGroups = {
        DataSourceGroups = [{"DataSourceId" : "SalesforceCustomerDocsGroup", "GroupId": "Sales and Marketing"}]
    })

按属性筛选

查询索引时，您可以使用内置属性，_user_id并_group_id根据用户及其群组对文档的访问权限筛选搜索结果。您最多可以设置 100 个群组标识符。当您发出查询时， Amazon Kendra 会检查用户和群组信息并运行查询。将返回与用户有权访问的查询相关的所有文档，包括公共文档。

你在AttributeFilter对象中提供用户和群组属性，然后在 Query API 中传递这些属性。

以下示例显示了一个请求，该请求根据用户 ID 以及用户所属的“HR”和“IT”组筛选查询响应。该查询将返回允许列表中包含用户或“HR”或“IT”组的所有文档。如果该用户或其中一个组在文档的拒绝列表中，则不会返回该文档。

response = kendra.query(
        QueryText = query,
        IndexId = index,
        AttributeFilter = {
            "OrAllFilters": [
                {
                    "EqualsTo": {
                        "Key": "_user_id",
                        "Value": {
                            "StringValue": "user1"
                        }
                     }
                },
                {
                    "EqualsTo": {
                        "Key": "_group_ids",
                        "Value": {
                            "StringListValue": ["HR", "IT"]
                        }
                    }
                }
            ]
        }
        )

您还可以在Principal对象中指定群组可以访问哪个数据来源。

注意

用户上下文筛选不是对内容的身份验证或授权控制。它不会对发送到 Query API 的用户和群组进行用户身份验证。您的应用程序有责任确保发送到 Query API 的用户和群组信息经过身份验证和授权。

每个数据来源都实现了用户上下文筛选。以下部分描述了每种实现。

对直接添加到索引的文档进行用户上下文筛选

使用 BatchPutDocumentAPI 将文档直接添加到索引时， Amazon Kendra 会从文档的AccessControlList字段中获取用户和群组信息。您为文档提供访问控制列表（ACL），ACL 随文档一起提取。

您可以在 BatchPutDocument API 中将 Princip al 对象中的 ACL 指定为 Doc ument 对象的一部分。提供以下信息：

• 用户或组应具有的访问权限。您可以说ALLOW或DENY。

• 实体的类型。您可以说USER或GROUP。

• 用户或组的名称。

您最多可以在AccessControlList字段中添加 200 个条目。

筛选用户上下文以查找常见问题

向索引添加常见问题解答时， Amazon Kendra 会从 FAQ JSON 文件的AccessControlList对象/字段中获取用户和群组信息。您也可以使用带有自定义字段或属性的常见问题 CSV 文件进行访问控制。

提供以下信息：

• 用户或组应具有的访问权限。您可以说ALLOW或DENY。

• 实体的类型。您可以说USER或GROUP。

• 用户或组的名称。

有关更多信息，请参阅 常见问题。

数据来源的用户上下文筛选

Amazon Kendra 还会从支持的数据源连接器中搜寻用户和组访问控制列表 (ACL) 信息。这对于用户上下文筛选非常有用，在这种筛选中，搜索结果是根据用户或其群组对文档的访问权限进行筛选的。

主题

• 针对 Adobe 体验管理器数据来源的用户上下文筛选
• Alfresco 数据来源的用户上下文筛选
• 针对 Aurora (MySQL) 数据源的用户上下文筛选
• 筛选 Aurora （PostgreSQL）数据来源的用户上下文
• Amazon FSx 数据源的用户上下文筛选
• 数据库数据来源的用户上下文筛选
• Amazon RDS （ Microsoft SQL Server）数据来源的用户上下文筛选
• 针对 Amazon RDS (MySQL) 数据源的用户上下文筛选
• 筛选 Amazon RDS (Oracle) 数据源的用户上下文
• 筛选 Amazon RDS （PostgreSQL）数据来源的用户上下文
• Amazon S3 数据来源的用户上下文筛选
• Amazon WorkDocs 数据源的用户上下文筛选
• Box 数据来源的用户上下文筛选
• Confluence 数据来源的用户上下文筛选
• 针对 Dropbox 数据来源的用户上下文筛选
• Drupal 数据来源的用户上下文筛选
• GitHub 数据源的用户上下文筛选
• Gmail 数据来源的用户上下文筛选
• 筛选 Google 云端硬盘数据来源的用户上下文
• 筛选 IBM DB2 数据来源的用户上下文
• Jira 数据来源的用户上下文筛选
• Microsoft Exchange 数据来源的用户上下文筛选
• 微软 OneDrive 数据源的用户上下文筛选
• 微软 OneDrive v2.0 数据源的用户上下文筛选
• 微软 SharePoint 数据源的用户上下文筛选
• Microsoft SQL Server 数据来源的用户上下文筛选
• Microsoft 团队数据来源的用户上下文筛选
• Microsoft Yammer 数据来源的用户上下文筛选
• 针对 MySQL 数据来源的用户上下文筛选
• 筛选 Oracle 数据库数据来源的用户上下文
• PostgreSQL 数据来源的用户上下文筛选
• Quip 数据来源的用户上下文筛选
• Salesforce 数据来源的用户上下文筛选
• ServiceNow 数据来源的用户上下文筛选
• Slack 数据来源的用户上下文筛选
• Zendesk 数据来源的用户上下文筛选

针对 Adobe 体验管理器数据来源的用户上下文筛选

当您使用 Adobe Experience Manager 数据源时， Amazon Kendra 会从 Adobe Experience Manager 实例获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids-群组 ID 存在于 Adobe Experience Manager 内容中，其中设置了访问权限。它们是从 Adobe 体验管理器中的群组名称映射出来的。

• _user_id-用户 ID 存在于 Adobe Experience Manager 内容中，其中设置了访问权限。它们从用户电子邮件中映射为 Adobe Experience Manager 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Alfresco 数据来源的用户上下文筛选

当你使用 Alfresco 数据源时， Amazon Kendra 会从 Alfresco 实例中获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids-群组 ID 存在于 Alfresco 中设置了访问权限的文件上。它们是从 Alfresco 中组的系统名称（不是显示名称）映射出来的。

• _user_id-Alfresco 中存在已设置访问权限的文件上的用户 ID。它们从用户电子邮件中映射为 Alfresco 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

针对 Aurora (MySQL) 数据源的用户上下文筛选

使用 Aurora (MySQL) 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Aurora (MySQL) 数据库数据源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

筛选 Aurora （PostgreSQL）数据来源的用户上下文

使用 Aurora (PostgreSQL) 数据源时 Amazon Kendra ，会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Aurora (PostgreSQL) 数据库数据源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Amazon FSx 数据源的用户上下文筛选

使用 Amazon FSx 数据源时， Amazon Kendra 会从 Amazon FSx 实例的目录服务中获取用户和组信息。

群 Amazon FSx 组和用户 ID 映射如下：

• _group_ids-群组 ID 存在 Amazon FSx 于设置了访问权限的文件中。它们是从的目录服务中的系统组名称映射出来的 Amazon FSx。

• _user_id—用户 ID 存在 Amazon FSx 于设置了访问权限的文件中。它们是从的目录服务中的系统用户名映射出来的 Amazon FSx。

您最多可以在AccessControlList字段中添加 200 个条目。

数据库数据来源的用户上下文筛选

当您使用数据库数据源（例如）时 Amazon Aurora PostgreSQL， Amazon Kendra 会从源表的某一列中获取用户和组信息。您可以在 CreateDataSourceAPI 中将此列指定为AclConfigurationDatabaseConfiguration对象的一部分。

数据库数据来源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Amazon RDS （ Microsoft SQL Server）数据来源的用户上下文筛选

当你使用 Amazon RDS （Microsoft SQL Server）数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Amazon RDS （微软 SQL Server）数据库数据源有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

针对 Amazon RDS (MySQL) 数据源的用户上下文筛选

使用 Amazon RDS (MySQL) 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Amazon RDS (MySQL) 数据库数据源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

筛选 Amazon RDS (Oracle) 数据源的用户上下文

使用 Amazon RDS (Oracle) 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Amazon RDS (Oracle) 数据库数据源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

筛选 Amazon RDS （PostgreSQL）数据来源的用户上下文

使用 Amazon RDS (PostgreSQL) 数据源时 Amazon Kendra ，会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Amazon RDS (PostgreSQL) 数据库数据源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Amazon S3 数据来源的用户上下文筛选

您可以使用与文档关联的元数据文件向 Amazon S3 数据源中的文档添加用户上下文筛选。您可以将信息添加到 JSON 文档的AccessControlList字段中。有关向从数据来源编制索引的文档中添加元 Amazon S3 数据的更多信息，请参阅 S3 文档元数据。

您提供三条信息：

• 实体应拥有的访问权限。您可以说ALLOW或DENY。

• 实体的类型。您可以说USER或GROUP。

• 在 中，将实体命名为 。

您最多可以在AccessControlList字段中添加 200 个条目。

Amazon WorkDocs 数据源的用户上下文筛选

当您使用 Amazon WorkDocs 数据源时， Amazon Kendra 会从该 Amazon WorkDocs 实例获取用户和群组信息。

群 Amazon WorkDocs 组和用户 ID 映射如下：

• _group_ids—群组 ID 存在 Amazon WorkDocs 于设置了访问权限的文件中。它们是根据中组的名称映射出来的 Amazon WorkDocs。

• _user_id—用户 ID 存在 Amazon WorkDocs 于设置了访问权限的文件中。它们是根据中的用户名映射出来的 Amazon WorkDocs。

您最多可以在AccessControlList字段中添加 200 个条目。

Box 数据来源的用户上下文筛选

使用 Box 数据源时， Amazon Kendra 会从 Box 实例获取用户和群组信息。

Box 组和用户 ID 映射如下：

• _group_ids-群组 ID 存在于 Box 中设置了访问权限的文件上。它们是从 Box 中群组的名称映射出来的。

• _user_id-用户 ID 存在于 Box 中设置了访问权限的文件中。它们从用户电子邮件中映射为 Box 中的用户 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Confluence 数据来源的用户上下文筛选

当您使用 Confluence 数据源时， Amazon Kendra 会从 Confluence 实例获取用户和群组信息。

您可以使用空间权限页面配置用户和群组对空间的访问权限。对于页面和博客，您可以使用限制页面。有关空间权限的更多信息，请参阅 Confluence Support 网站上的空间权限概述。有关页面和博客限制的更多信息，请参阅 Confluence Support 网站上的页面限制。

Confluence 群组和用户名映射如下：

• _group_ids-群组名称会出现在有限制的空间、页面和博客上。它们是根据 Confluence 中的群组名称映射出来的。群组名称始终为小写。

• _user_id- 用户名出现在空间、页面或博客上有限制的地方。它们根据您使用的 Confluence 实例的类型进行映射。

  适用于 Confluence 连接程序 v1.0

  • 服务器-_user_id 是用户名。用户名始终为小写。

  • 云端-_user_id 是用户的账户 ID。

  适用于 Confluence 连接器 v2.0

  • 服务器-_user_id 是用户名。用户名始终为小写。

  • Cloud-_user_id 是用户的电子邮件 ID。

  重要

  要使用户上下文筛选功能在 Confluence 连接器上正常运行，您需要确保将获得 Confluence 页面访问权限的用户的可见性设置为“任何人”。有关更多信息，请参阅 Atlassian 开发者文档中的设置电子邮件可见性。

您最多可以在AccessControlList字段中添加 200 个条目。

针对 Dropbox 数据来源的用户上下文筛选

当您使用 Dropbox 数据源时， Amazon Kendra 会从 Dropbox 实例中获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids-群组 ID 存在于 Dropbox 中已设置访问权限的文件上。它们是从 Dropbox 中群组的名称映射出来的。

• _user_id-Dropbox 中存在已设置访问权限的文件中的用户 ID。它们从用户的电子邮件中映射为 Dropbox 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Drupal 数据来源的用户上下文筛选

当你使用 Drupal 数据源时， Amazon Kendra 会从 DrupalInstance 中获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids- 在 Drupal 中，群组 ID 存在于设置了访问权限的文件上。它们是根据Drupal中群组的名称映射出来的。

• _user_id- Drupal 中存在已设置访问权限的文件上的用户 ID。它们从用户电子邮件中映射为 Drupal 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

GitHub 数据源的用户上下文筛选

当您使用 GitHub 数据源时， Amazon Kendra 会从该 GitHub 实例获取用户信息。

GitHub 用户 ID 映射如下：

• _user_id—用户 ID 存在 GitHub 于设置了访问权限的文件中。它们从用户电子邮件中映射为中的 ID GitHub。

您最多可以在AccessControlList字段中添加 200 个条目。

Gmail 数据来源的用户上下文筛选

当你使用 Gmail 数据源时， Amazon Kendra 会从 Gmail 实例中获取用户信息。

用户 ID 映射如下：

• _user_id- Gmail 中设置了访问权限的文件中存在用户 ID。它们从用户的电子邮件中映射为 Gmail 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

筛选 Google 云端硬盘数据来源的用户上下文

Google Workspace 云端硬盘数据来源会返回谷歌云端硬盘用户和群组的用户和群组信息。组和域成员资格映射到_group_ids索引字段。Google 云端硬盘用户名将映射到该_user_id字段。

当您在 Query API 中提供一个或多个用户电子邮件地址时，仅返回与这些电子邮件地址共享的文档。以下AttributeFilter参数仅返回与“[e-mail]”共享的文档。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_user_id", 
                   "Value": {
                       "StringValue": "[e-mail]"
                   }
               }
           }

如果您在查询中提供一个或多个群组电子邮件地址，则仅返回与群组共享的文档。以下AttributeFilter参数仅返回与“[e-mail]”群组共享的文档。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_group_ids", 
                   "Value": {
                       "StringListValue": ["[e-mail]"]
                   }
               }
           }

如果您在查询中提供了域，则会返回与该域共享的所有文档。以下AttributeFilter参数返回与“example.com”域共享的文档。

"AttributeFilter": {
                "EqualsTo":{
                   "Key": "_group_ids", 
                   "Value": {
                       "StringListValue": ["example.com"]
                   }
               }
           }

您最多可以在AccessControlList字段中添加 200 个条目。

筛选 IBM DB2 数据来源的用户上下文

使用 IBM DB2 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

IBM DB2 数据库数据来源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Jira 数据来源的用户上下文筛选

使用 Jira 数据源时， Amazon Kendra 会从 Jira 实例获取用户和群组信息。

Jira 用户 ID 的映射如下所示：

• _user_id-Jira 中存在已设置访问权限的文件上的用户 ID。它们从用户电子邮件中映射为 Jira 中的用户 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Microsoft Exchange 数据来源的用户上下文筛选

当你使用微软 Exchange 数据源时， Amazon Kendra 会从微软 Exchange 实例获取用户信息。

微软 Exchange 用户 ID 映射如下：

• _user_id— 用户名存在于微软 Exchange 权限中，用户可以访问某些内容。它们从用户名映射为微软 Exchange 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

微软 OneDrive 数据源的用户上下文筛选

Amazon Kendra 在 Microsoft 为站点上的文档编制索引 OneDrive 时，会从 Microsoft 检索用户和群组信息。用户和群组信息取自托管的底层 Microsoft SharePoint 站点 OneDrive。

使用 OneDrive 用户或群组筛选搜索结果时，按如下方式计算 ID：

1. 获取网站名称。例如，https://host.onmicrosoft.com/sites/siteName.

2. 以网站名称的 MD5 哈希值为例。例如，430a6b90503eef95c89295c8999c7981。

3. 将 MD5 哈希值与竖线（|）和 ID 连接起来，创建用户电子邮件或群组 ID。例如，如果群组名称是 localGroupName “”，则群组 ID 将是：

   "430a6b90503eef95c89295c8999c7981 | localGroupName"

   注意

   在竖线前后各留一个空格。竖条用于标识localGroupName其 MD5 哈希值。

   对于用户名“[e-mail]”，用户 ID 将如下所示：

   "430a6b90503eef95c89295c8999c7981 | [e-mail]"

在调用查询 API 时，将用户_user_id或群组 ID Amazon Kendra 作为或_group_id属性发送到。例如，使用群组筛选搜索结果的 AWS CLI 命令如下所示：

aws kendra  query \
                --index-id index ID  
                --query-text "query text" 
                --attribute-filter '{
                   "EqualsTo":{
                     "Key": "_group_id", 
                     "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"}
                  }}'

您最多可以在AccessControlList字段中添加 200 个条目。

微软 OneDrive v2.0 数据源的用户上下文筛选

Microsoft OneDrive v2.0 数据源返回来自 OneDrive 访问控制列表 (ACL) 实体的分区和页面信息。 Amazon Kendra 使用 OneDrive 租户域连接到 OneDrive 实例，然后可以根据用户或群组对分区和文件名的访问权限筛选搜索结果。

对于标准对象，_user_id和_group_id的使用方式如下：

• _user_id— 你的 Microsoft OneDrive 用户电子邮件 ID 已映射到该_user_id字段。

• _group_id— 你的 Microsoft OneDrive 群组电子邮件已映射到该_group_id字段。

您最多可以在AccessControlList字段中添加 200 个条目。

微软 SharePoint 数据源的用户上下文筛选

Amazon Kendra 在 Microsoft 为站点文档编制索引 SharePoint 时，会从 Microsoft 检索用户和群组信息。要根据用户或群组访问权限筛选搜索结果，请在调用 Query API 时提供用户和群组信息。

要使用用户名进行筛选，请使用该用户的电子邮件地址。例如，[e-mail]。

使用 SharePoint 群组筛选搜索结果时，按如下方式计算群组 ID：

对于本地团体

1. 获取网站名称。例如，https://host.onmicrosoft.com/sites/siteName.

2. 取站点名称的 SHA256 哈希。例如，430a6b90503eef95c89295c8999c7981。

3. 通过将 SHA256 哈希值与竖线（|）和群组名称连接起来来创建群组 ID。例如，如果群组名为 localGroupName “”，则群组 ID 将是：

   "430a6b90503eef95c89295c8999c7981 | localGroupName"

   注意

   在竖线前后各留一个空格。竖条用于标识localGroupName其 SHA256 哈希值。

调用查询 API 时，将群组 ID Amazon Kendra 作为_group_id属性发送到。例如，该 AWS CLI 命令如下所示：

aws kendra  query \
                --index-id index ID  
                --query-text "query text" 
                --attribute-filter '{
                   "EqualsTo":{
                     "Key": "_group_id", 
                     "Value": {"StringValue": "430a6b90503eef95c89295c8999c7981 | localGroupName"}
                  }}'

适用于 AD 组

1. 使用 AD 组 ID 来配置对搜索结果的筛选。

调用查询 API 时，将群组 ID Amazon Kendra 作为_group_id属性发送到。例如，该 AWS CLI 命令如下所示：

aws kendra  query \
                --index-id index ID  
                --query-text "query text" 
                --attribute-filter '{
                   "EqualsTo":{
                     "Key": "_group_id", 
                     "Value": {"StringValue": "AD group"}
                  }}'

您最多可以在AccessControlList字段中添加 200 个条目。

Microsoft SQL Server 数据来源的用户上下文筛选

当你使用 Microsoft SQL Server 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Microsoft SQL Server 数据库数据来源有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Microsoft 团队数据来源的用户上下文筛选

Amazon Kendra 在为文档编制索引时，会从 Microsoft Teams 中检索用户信息。用户信息取自底层的 Microsoft Teams 实例。

您最多可以在AccessControlList字段中添加 200 个条目。

Microsoft Yammer 数据来源的用户上下文筛选

Amazon Kendra 在为文档编制索引时，会从 Microsoft Yammer 中检索用户信息。用户和群组信息取自底层的 Microsoft Yammer 实例。

Microsoft Yammer 用户 ID 映射如下：

• _email_id— 映射到该_user_id字段的 Microsoft 电子邮件 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

针对 MySQL 数据来源的用户上下文筛选

使用 MySQL 数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

MySQL 数据库数据来源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

筛选 Oracle 数据库数据来源的用户上下文

使用 Oracle 数据库数据源时， Amazon Kendra 会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

Oracle 数据库数据来源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

PostgreSQL 数据来源的用户上下文筛选

使用 PostgreSQL 数据源时 Amazon Kendra ，会从源表中的一列中获取用户和组信息。您可以在控制台中指定此列，或者使用TemplateConfiguration对象作为 CreateDataSourceAPI 的一部分。

PostgreSQL 数据库数据来源具有以下限制：

• 您只能为数据库数据来源指定允许列表。您无法指定拒绝列表。

• 您只能指定群组。您不能为允许列表指定单个用户。

• 数据库列应是一个包含以分号分隔的组列表的字符串。

Quip 数据来源的用户上下文筛选

当您使用 Quip 数据源时， Amazon Kendra 会从 Quip 实例获取用户信息。

Quip 用户 ID 的映射如下所示：

• _user_id-Quip 中存在已设置访问权限的文件上的用户 ID。它们从用户电子邮件中映射为 Quip 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Salesforce 数据来源的用户上下文筛选

Salesforce 数据来源返回来自 Salesforce 访问控制列表（ACL）实体的用户和群组信息。您可以将用户上下文筛选应用于 Salesforce 标准对象和聊天提要。用户上下文筛选不适用于 Salesforce 知识文章。

如果您将任何 Salesforce 字段映射到 Amazon Kendra 文档标题和文档正文字段，Amazon Kendra 将在搜索响应中使用来自文档标题和正文字段的数据。

对于标准对象，_user_id和_group_ids的使用方式如下：

• _user_id- Salesforce 用户的用户名。

• _group_ids—

  • Salesforce 的名字 Profile

  • Salesforce 的名字 Group

  • Salesforce 的名字 UserRole

  • Salesforce 的名字 PermissionSet

对于 chatter Feed，_user_id和_group_ids的使用方式如下：

• _user_id- Salesforce 用户的用户名。仅当该项目发布在用户的 Feed 中时才可用。

• _group_ids-群组 ID 的使用方式如下。仅当 Feed 项目在聊天或协作群组中发布时才可用。

  • 聊天群组或协作群组的名称。

  • 如果该群组是公开的，PUBLIC:ALL.

您最多可以在AccessControlList字段中添加 200 个条目。

ServiceNow 数据来源的用户上下文筛选

只有 TemplateConfiguration API 和 ServiceNow ServiceNow Connector v2.0 支持用户上下文筛选。 ServiceNowConfigurationAPI 和 ServiceNow 连接器 v1.0。不支持用户上下文筛选。

当您使用 ServiceNow 数据源时， Amazon Kendra 会从该 ServiceNow 实例获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids—群组 ID 存在 ServiceNow 于设置了访问权限的文件中。它们是根据中的角色名称映射而来sys_ids的 ServiceNow。

• _user_id—用户 ID 存在 ServiceNow 于设置了访问权限的文件中。它们从用户电子邮件中映射为中的 ID ServiceNow。

您最多可以在AccessControlList字段中添加 200 个条目。

Slack 数据来源的用户上下文筛选

当你使用 Slack 数据源时， Amazon Kendra 会从 Slack 实例中获取用户信息。

Slack 用户 ID 的映射如下所示：

• _user_id- Slack 中存在设置访问权限的消息和频道上的用户 ID。它们从用户电子邮件中映射为 Slack 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。

Zendesk 数据来源的用户上下文筛选

当你使用 Zendesk 数据源时， Amazon Kendra 会从 Zendesk 实例中获取用户和群组信息。

群组和用户 ID 映射如下：

• _group_ids-群组 ID 存在于设置访问权限的 Zendesk 工单和文章中。它们是从 Zendesk 中的群组名称映射出来的。

• _user_id-群组 ID 存在于设置访问权限的 Zendesk 工单和文章中。它们从用户电子邮件中映射为 Zendesk 中的 ID。

您最多可以在AccessControlList字段中添加 200 个条目。