使用 Amazon Verified Permissions 进行授权 - Amazon Cognito
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

使用 Amazon Verified Permissions 进行授权

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

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

当应用程序在 IsAuthorizedWithToken API 请求中提供令牌时,Verified Permissions 将执行以下验证。

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

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

  3. 您的令牌未过期。

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

  5. 令牌中的签名来自用户群体中已发布的 JSON Web 密钥(JWK)。您可以在 https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json 中查看您的 JWK。

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

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

策略评估

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

自定义令牌

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

注意

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

有关 Verified Permissions 如何将 Amazon Cognito 令牌中的声明映射到授权策略的更多信息,请参阅将 Amazon Cognito 令牌映射到 Verified Permissions 架构

使用已验证权限的 API 授权

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

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

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

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

选择策略存储设置

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

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

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

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

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

以下示例策略是通过为示PetStore例 REST API 设置已验证权限策略存储而创建的。

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 是应用程序中的用户,他从应用程序客户端接收 ID 令牌,并在 GET 请求中将其传递到需要授权的 URL https://example.com/images/example_image.png。John 的 ID 令牌拥有用户群体应用程序客户端 ID 1234567890exampleaud 声明。令牌生成前 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 );

以下是一个示例

基于属性的访问控制

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

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