使用 Amazon Verified Permissions 进行授权 - Amazon Cognito
API使用经过验证的权限进行授权Amazon Cognito 用户的示例策略

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用 Amazon Verified Permissions 进行授权

Amazon Verified Permissions 是针对您构建的应用程序的授权服务。当您将 Amazon Cognito 用户群体添加为身份源时，应用程序可以将用户群体访问权限或身份（ID）令牌传递给 Verified Permissions，以便做出允许或拒绝决定。Verified Permissions 根据您使用 Cedar 策略语言编写的策略，来考虑用户的属性和请求上下文。请求上下文可以包括所请求的文档、映像或其他资源的标识符，以及用户想要对该资源采取的操作。

您的应用程序可以在或BatchIsAuthorizedWithTokenAPI请求中向已验证的权限提供用户的身份IsAuthorizedWithToken或访问令牌。这些API操作接受您的用户作为Principal并对他们想要访问Resource的用户做出授权决定。Action其他自定义Context可以帮助做出详细的访问决策。

当您的应用程序在IsAuthorizedWithTokenAPI请求中提供令牌时，已验证的权限会执行以下验证。

  1. 您的用户群体是针对所请求的策略存储而配置的 Verified Permissions 身份来源。

  2. 访问令牌或身份令牌中的 client_id 或 aud 声明分别与您提供给 Verified Permissions 的用户群体应用程序客户端 ID 相匹配。要验证此声明，您必须在 Verified Permissions 身份来源中配置客户端 ID 验证。

  3. 您的令牌未过期。

  4. 您的令牌中的token_use索赔值与您传递给的参数相匹配IsAuthorizedWithToken。token_use声明必须是access您将其传递给accessToken参数以及id是否将其传递给identityToken参数。

  5. 令牌中的签名来自用户池中已发布的JSON网络密钥 (JWKs)。你可以查看你的 JWKs athttps://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json.

已撤销的令牌和已删除的用户

Verified Permissions 仅验证它从您的身份来源和用户令牌到期时间所了解的信息。Verified Permissions 不检查令牌是否撤销或用户是否存在。如果您从用户群体中撤销了用户的令牌或删除了用户的配置文件，则 Verified Permissions 在令牌到期之前仍会认为该令牌有效。

策略评估

将您的用户群体配置为策略存储的身份来源。将您的应用程序配置为在对 Verified Permissions 的请求中提交用户的令牌。对于每个请求，Verified Permissions 将令牌中的声明与策略进行比较。“已验证权限” 策略类似于中的IAM策略 AWS。该策略会声明主体、资源 和操作。Allow如果您的请求与允许的操作匹配且与显式Deny操作不匹配，则验证权限会对您的请求做出响应；否则，它会响应Deny。有关更多信息，请参阅《Amazon Verified Permissions 用户指南》中的 Amazon Verified Permissions 策略。

自定义令牌

要更改、添加和删除您要向已验证权限提供的用户声明，请使用自定义访问和身份令牌中的内容令牌生成前 Lambda 触发器。使用令牌生成前触发器，您可以在令牌中添加和修改声明。例如，您可以在数据库中查询其他用户属性，并将这些属性编码为您的 ID 令牌。

注意

由于 Verified Permissions 处理声明的方式，请勿在令牌生成前函数中添加名为 cognito、dev 或 custom 的声明。如果您提供的这些保留的声明前缀不是采用以冒号分隔的格式（例如 cognito:username），而是采用完整的声明名称，则您的授权请求会失败。

其他 资源

API使用经过验证的权限进行授权

您的身份证或访问令牌可以通过已验证的权限授权向后端 Amazon API Gatew REST APIs ay 发出的请求。您可以创建一个策略存储，其中包含指向您的用户池的即时链接，以及API. 使用 “开始使用 Co gnito 和 API Gateway 进行设置” 选项，“已验证权限” 会将用户池身份源添加到策略存储中，将 Lambda 授权者添加到策略存储中。API当您的应用程序将用户池持有者令牌传递给时API，Lambda 授权方会调用已验证的权限。授权方将令牌作为委托人传递，将请求路径和方法作为操作传递。

下图说明了API具有已验证权限的API网关的授权流程。有关详细详情，请参阅《Amazon 已验证权限用户指南》中存储的API关联策略。

此图说明了使用 Amazon 验证权限的API授权流程。应用程序向 Amazon API Gateway 发出请求API。API调用 Lambda 授权器。授权者向已验证的权限API提出请求。已验证权限会检查令牌的有效性并返回授权决定。

已验证权限围绕用户池组进行API授权。由于 ID 和访问令牌都包含cognito:groups声明，因此您的策略存储可以在各种应用程序上下文APIs中为您管理基于角色的访问控制 (RBAC)。

选择策略存储设置

在策略存储上配置身份源时，必须选择是要处理访问令牌还是 ID 令牌。此决定对您的策略引擎的运作方式具有重要意义。ID 令牌包含用户属性。访问令牌包含用户访问控制信息：OAuth范围。尽管两种令牌类型都有群组成员资格信息，但我们通常建议使用已验证权限策略存储RBAC库的访问令牌。访问令牌可增加群组成员资格，其范围可以促成授权决策。访问令牌中的声明成为授权请求中的上下文。

在将用户池配置为身份源时，还必须配置用户和组实体类型。实体类型是您可以在 “已验证权限” 策略中引用的委托人、操作和资源标识符。策略存储中的实体可以具有成员关系，其中一个实体可以是父实体的成员。通过成员资格，您可以引用负责人小组、操作组和资源组。对于用户池群组，您指定的用户实体类型必须是该组实体类型的成员。当您在已验证权限控制台中设置API链接策略存储或按照指导设置操作时，您的策略存储会自动具有这种父成员关系。

ID 令牌可以RBAC与基于属性的访问控制 () ABAC 结合使用。创建API链接策略存储后，您可以使用用户属性和群组成员资格来增强您的策略。ID 令牌中的属性声明成为授权请求中的主体属性。您的策略可以根据委托人属性做出授权决定。

您也可以将策略存储配置为接受与您提供的可接受应用程序客户端列表相匹配的aud或client_id声明的令牌。

基于角色API的授权策略示例

以下示例策略是通过设置已验证权限策略存储库创建PetStore的RESTAPI。

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

在以下情况下，已验证的权限会返回对您的应用程序的授权请求的Allow决定：

  1. 您的应用程序在Authorization标头中传递了 ID 或访问令牌作为持有者令牌。

  2. 您的应用程序传递了一个带有cognito:groups声明的令牌，其中包含该字符串MyGroup。

  3. 例如，您的应用程序向https://myapi.example.com/pets或发出了HTTP GET请求https://myapi.example.com/pets/scrappy。

Amazon Cognito 用户的示例策略

您的用户池还可以在请求以外的条件下生成对已验证权限的授权API请求。您可以将应用程序中的任何访问控制决策提交到策略存储区。例如，您可以在任何请求通过网络之前通过基于属性的访问控制来补充 Amazon DynamoDB 或 Amazon S3 的安全性，从而减少配额使用量。

以下示例使用 Cedar 策略语言，以允许通过一个用户群体应用程序客户端进行身份验证的财务用户读写 example_image.png。John 是您应用程序中的用户，URL他从您的应用程序客户端收到一个 ID 令牌，然后通过GET请求将其传递给需要授权的https://example.com/images/example_image.png。John 的 ID 令牌拥有用户群体应用程序客户端 ID 1234567890example 的 aud 声明。令牌生成前 Lambda 函数还插入了一个新声明 costCenter，对于 John 来说，值为 Finance1234。

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

以下请求正文会导致 Allow 响应。

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

当您要在 Verified Permissions 策略中指定主体时，请使用以下格式：

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

以下是用户池中 ID 为 sub 或用户 ID us-east-1_Example 的用户的委托人示例973db890-092c-49e4-a9d0-912a4c0a20c7。

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

要在 “已验证权限” 策略中指定用户组时，请使用以下格式：

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

以下是一个示例

基于属性的访问控制

为您的应用程序提供经过验证的权限授权，以及用于 AWS 凭证的 Amazon Cognito 身份池的访问控制属性功能，都是基于属性的访问控制形式（）。ABAC以下是已验证权限和 Amazon Cognito ABAC 功能的比较。在中ABAC，系统会检查实体的属性并根据您定义的条件做出授权决定。

服务 过程 结果
Amazon Verified Permissions 根据对用户池的分析返回Allow或Deny决策JWT。 根据 Cedar 策略评估，应用程序资源的访问成功或失败。
Amazon Cognito 身份池（用于访问控制的属性） 根据用户的属性为其分配会话标签。IAM策略条件可以检查标签Allow或Deny用户访问权限 AWS 服务。 带有IAM角色临时 AWS 证书的标记会话。