本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon 已验证权限和 Cedar 政策语言术语和概念 要使用 Amazon Verified Permissions，您应该了解以下概念。 **Topics** + [授权模型](#term-authorization-model) + [授权请求](#term-authorization-request) + [授权响应](#term-authorization-response) + [考虑的策略](#term-considered-policies) + [上下文数据](#term-context-data) + [决定性策略](#term-determining-policies) + [实体数据](#term-entity-data) + [权限、授权和主体](#term-permissions-authorization-principals) + [策略执行](#term-policy-enforcement) + [策略存储](#term-policy-store) + [策略存储别名](#term-policy-store-alias) + [策略名称](#term-policy-name) + [策略模板名称](#term-policy-template-name) + [满足条件的策略](#term-satisfied-policies) + [Amazon 验证权限与 Cedar 政策语言之间的区别](terminology-differences-avp-cedar.md) **Cedar 策略语言概念** + [授权](https://docs.cedarpolicy.com/overview/terminology.html#authorization) + [实体](https://docs.cedarpolicy.com/overview/terminology.html#entity) + [组和层次结构](https://docs.cedarpolicy.com/overview/terminology.html#term-group) + [命名空间](https://docs.cedarpolicy.com/policies/validation.html#namespaces) + [Policy](https://docs.cedarpolicy.com/overview/terminology.html#policy) + [策略模板](https://docs.cedarpolicy.com/overview/terminology.html#policy-template) + [架构](https://docs.cedarpolicy.com/overview/terminology.html#schema) ## 授权模型 *授权模型*描述了应用程序发出的[授权请求](#term-authorization-request)的范围，以及评估这些请求的依据。它是根据不同类型的资源、对这些资源执行的操作以及执行这些操作的主体类型来定义的，同时还考虑了执行这些操作的上下文。 *基于角色的访问权限控制（RBAC）*是一种评估基础，其会定义各种角色并将这些角色与一组权限相关联。之后，这些角色就可以分配给一个或多个身份。分配到该角色的身份会获得与该角色关联的权限。如果修改了与该角色关联的权限，则此项修改会自动影响分配到该角色的所有身份。Cedar 通过使用主体组来支持 RBAC 决策。 *基于属性的访问权限控制（ABAC）*是一种评估基础，其中，与身份关联的权限由该身份的属性决定。Cedar 通过使用引用主体属性的策略条件来支持 ABAC 决策。 Cedar 策略语言允许为具有基于属性的条件的一组用户定义权限，从而将 RBAC 和 ABAC 组合到一个策略中。 ## 授权请求 *授权请求*是应用程序对 Verified Permissions 发出的请求，用于评估一组策略，以确定主体是否可以在给定上下文中对资源执行操作。 ## 授权响应 *授权响应*是对[授权请求](#term-authorization-request)的响应，它包括允许或拒绝的决定，以及其他信息，例如决定性策略的信息。 IDs ## 考虑的策略 *考虑的策略*是指在评估[授权请求](#term-authorization-request)时，由 Verified Permissions 选择包含的完整策略集。 ## 上下文数据 *上下文数据*是提供要评估的额外信息的属性值。 ## 决定性策略 *决定性策略*是决定[授权响应](#term-authorization-response)的策略。例如，如果有两个[满足条件的策略](#term-satisfied-policies)，其中一个是拒绝，另一个是允许，那么，拒绝策略将成为决定性策略。如果存在多个满足条件的允许策略且没有满足条件的禁止策略，那么就会存在多个决定性策略。如果没有匹配的策略，并且响应是拒绝，那么就不存在决定性策略。 ## 实体数据 *实体数据*是有关主体、操作和资源的数据。与策略评估相关的实体数据包括实体层次结构中的组成员关系，以及主体和资源的属性值。 ## 权限、授权和主体 Verified Permissions 管理您构建的自定义应用程序中的精细*权限*和*授权*。 *主体*是指将身份绑定到用户名或机器 ID 等标识符的应用程序的用户（人类或机器）。身份验证过程会确定主体是否确实是其所声称的身份。 与该身份关联的是一组应用程序*权限*，这些权限决定了允许该主体在该应用程序中执行哪些操作。*授权*是评估这些权限以确定是否允许主体在应用程序中执行特定操作的过程。这些权限可以表示为[策略](https://docs.cedarpolicy.com/overview/terminology.html#policy)。 ## 策略执行 *策略执行*是在 Verified Permissions 之外的应用程序中执行评估决策的过程。如果 Verified Permissions 评估返回的结果为拒绝，则执行将确保禁止主体访问资源。 ## 策略存储 *策略存储*是策略和模板的容器。每个存储都包含一个架构，用于验证添加到存储中的策略。默认情况下，每个应用程序都有自己的策略存储，但多个应用程序可以共享一个策略存储。当应用程序发出授权请求时，它会识别用于评估该请求的策略存储。策略存储提供了一种隔离策略集的方式，因此可以在多租户应用程序中使用，以包含每个租户的架构和策略。单个应用程序可以为每个租户提供单独的策略存储。 在评估[授权请求](#term-authorization-request)时，Verified Permissions 仅会考虑策略存储中与该请求相关的策略子集。相关性是根据策略的*范围*确定的。范围确定了策略适用的特定主体和资源，以及主体可以对资源执行的操作。定义范围有助于缩小考虑的策略集的范围，从而提高性能。 ## 策略存储别名 *策略存储别名*是策略存储的友好名称。在任何接受`policyStoreId`参数的已验证权限操作中，您可以使用策略存储别名来标识策略存储。策略存储别名是独立的 AWS 资源，有自己的 ARNs别名。每个别名一次只能与一个策略存储关联，多个别名可以与同一个策略存储关联。有关更多信息，请参阅 [Amazon 已验证权限策略存储别名](policy-store-aliases.md)。 ## 策略名称 *策略名称*是策略的可选友好名称。策略存储区内所有策略的策略名称必须是唯一的，并以`name/`此为前缀。在接受`policyId`参数的控制平面操作中，您可以使用策略名称代替策略 ID。可以在创建或更新策略时设置名称。只`GetPolicy`在输出中`ListPolicies`返回名称。 ## 策略模板名称 *策略模板名称*是策略模板的可选友好名称。策略存储区内所有策略模板的策略模板名称必须是唯一的，并以`name/`此为前缀。在接受`policyTemplateId`参数的控制平面操作中，您可以使用策略模板名称代替策略模板 ID。可以在创建或更新策略模板时设置名称。只`GetPolicyTemplate`在输出中`ListPolicyTemplates`返回名称。 ## 满足条件的策略 *满足条件的策略*是指与[授权请求](#term-authorization-request)的参数相匹配的策略。 # Amazon 验证权限与 Cedar 政策语言之间的区别 Amazon Verified Permissions 使用 Cedar 策略语言引擎来执行其授权任务。但是，原生 Cedar 实现与 Verified Permissions 中的 Cedar 实现之间存在一些差异。本主题揭示了二者之间存在的差异。 ## 命名空间定义 Verified Permissions 的 Cedar 实现与原生 Cedar 实现存在以下区别： + Verified Permissions 仅支持在策略存储中定义的[架构中的一个命名空间](https://docs.cedarpolicy.com/schema/schema.html#namespace)。 + Verified Permissions 不允许您创建空字符串或包含以下值的[命名空间](https://docs.cedarpolicy.com/schema/schema.html#namespace)：`aws``amazon`、或`cedar`。 ## 策略模板支持 Verified Permissions 和 Cedar 都只允许 `principal` 和 `resource` 范围内的占位符。但是，Verified Permissions 还要求 `principal` 和 `resource` 均不能不受限制。 以下策略在 Cedar 中有效，但由于 `principal` 不受限制，会被 Verified Permissions 拒绝。 ``` permit(principal, action == Action::"view", resource == ?resource); ``` 以下两个示例在 Cedar 和 Verified Permissions 中均有效，因为 `principal` 和 `resource` 都存在限制条件。 ``` permit(principal == User::"alice", action == Action::"view", resource == ?resource); ``` ``` permit(principal == ?principal, action == Action::"a", resource in ?resource); ``` ## 架构支持 Verified Permissions 要求所有架构 JSON 键名称均为非空字符串。在少数情况下，Cedar 允许使用空字符串，例如属性或命名空间。 ## 操作组定义 Cedar 授权方法要求提供实体列表，在对策略进行授权请求评估时需要考虑这些实体。 您可以在架构中定义应用程序使用的操作和操作组。但是，Cedar 不将架构作为评估请求的一部分，仅使用架构来验证您提交的策略和策略模板。由于 Cedar 在评估请求期间不会引用架构，因此，即使在架构中定义了操作组，您也需要将所有操作组的列表包含在必须传递给授权 API 操作的实体列表中。 Verified Permissions 可以为您执行此操作。您在架构中定义的所有操作组都会自动附加到您传递至的实体列表中，作为 `IsAuthorized` 或 `IsAuthorizedWithToken` 操作的参数。 ## 实体格式设置 使用`entityList`参数的 “已验证权限” 中实体的 JSON 格式与 Cedar 在以下方面有所不同： + 在 Verified Permissions 中，JSON 对象必须将其所有键值对包装在名为 `Record` 的 JSON 对象中。 + Verified Permissions 中的 JSON 列表必须包装在 JSON 键值对中，其中，键名称为 `Set`，值为来自 Cedar 的原始 JSON 列表。 + 对于 `String`、`Long` 和 `Boolean` 类型名称，在 Verified Permissions 中，Cedar 中的每个键值对都会被替换为 JSON 对象。该对象的名称是原始键名称。在 JSON 对象中，有一个键值对，其中键名称是标量值（`String`、`Long` 或 `Boolean`）的类型名称，值是来自 Cedar 实体的值。 + Cedar 实体和 Verified Permissions 实体的语法格式存在以下不同： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/verifiedpermissions/latest/userguide/terminology-differences-avp-cedar.html) **Example -清单** 以下示例分别显示了如何在 Cedar 和已验证权限中表示实体列表。 ``` [ { "number": 1 }, { "sentence": "Here is an example sentence" }, { "Question": false } ] ``` ``` { "Set": [ { "Record": { "number": { "Long": 1 } } }, { "Record": { "sentence": { "String": "Here is an example sentence" } } }, { "Record": { "question": { "Boolean": false } } } ] } ``` **Example -政策评估** 以下示例分别显示了 Cedar 和 Verified Permissions 中用于评估授权请求中的策略的实体是如何格式化的。 ``` [ { "uid": { "type": "PhotoApp::User", "id": "alice" }, "attrs": { "age": 25, "name": "alice", "userId": "123456789012" }, "parents": [ { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, { "type": "PhotoApp::UserGroup", "id": "AVTeam" } ] }, { "uid": { "type": "PhotoApp::Photo", "id": "vacationPhoto.jpg" }, "attrs": { "private": false, "account": { "__entity": { "type": "PhotoApp::Account", "id": "ahmad" } } }, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, "attrs": {}, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "AVTeam" }, "attrs": {}, "parents": [] } ] ``` ``` [ { "Identifier": { "EntityType": "PhotoApp::User", "EntityId": "alice" }, "Attributes": { "age": { "Long": 25 }, "name": { "String": "alice" }, "userId": { "String": "123456789012" } }, "Parents": [ { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" } ] }, { "Identifier": { "EntityType": "PhotoApp::Photo", "EntityId": "vacationPhoto.jpg" }, "Attributes": { "private": { "Boolean": false }, "account": { "EntityIdentifier": { "EntityType": "PhotoApp::Account", "EntityId": "ahmad" } } }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" }, "Parents": [] } ] ``` ## 长度和大小限制 Verified Permissions 支持以策略存储的形式存储您的架构、策略和策略模板。这种存储方式会导致 Verified Permissions 施加一些与 Cedar 无关的长度和大小限制。 | 对象 | Verified Permissions 限制（以字节为单位） | Cedar 极限 | | --- | --- | --- | | 策略大小¹ | 10000 | 无 | | 内联策略描述 | 150 | 不适用于 Cedar | | 策略模板大小 | 10000 | 无 | | 架构大小 | 100000 | 无 | | 实体类型 | 200 | 无 | | 策略 ID | 64 | 无 | | 策略模板 ID | 64 | 无 | | 实体 ID | 200 | 无 | | 策略存储 ID | 64 | 不适用于 Cedar | ¹ Verified Permissions 中的每个策略存储都有策略限制，具体取决于策略存储中创建的策略的主体、操作和资源的总组合大小。与单个资源相关的所有策略的总大小不能超过 200000 字节。在计算模板链接策略的大小时，策略模板的大小仅计算一次，再加上用于实例化每个模板链接策略的每组参数的大小。