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

# 示例 1：具有经过验证的权限和 Cedar 的基本 ABAC
<a name="avp-basic-abac-examples"></a>

在此示例场景中，Amazon 验证权限用于确定允许哪些用户访问虚构的 Payroll 微服务中的信息。本节包含 Cedar 代码片段，用于演示如何使用 Cedar 来做出访问控制决策。这些示例并不是为了全面探索 Cedar 和已验证权限提供的功能。有关 Cedar 的更全面概述，请参阅 [Cedar 文档](https://docs.cedarpolicy.com/)。

在下图中，我们想强制执行与该`viewSalary``GET`方法相关的两条一般业务规则：*员工可以查看自己的工资*，*员工可以查看向他们汇报的任何人的工资。*您可以使用已验证的权限策略来强制执行这些业务规则。

![使用 Amazon 验证权限和 Cedar 实现 PDP 的基本 ABAC 实施示例](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)


*员工可以查看自己的工资。*

在 Cedar 中，基本结构是一个*实体*，它代表委托人、行动或资源。要提出授权请求并使用已验证权限策略开始评估，您需要提供*委托人、**操作**、资源*和*实体列表。*
+ 委托人 (`principal`) 是登录的用户或角色。
+ 操作 (`action`) 是请求所评估的操作。
+ 资源 (`resource`) 是操作正在访问的组件。
+ 实体列表 (`entityList`) 包含评估请求所需的所有必需实体。

为了满足业务规则*员工可以查看自己的工资*，您可以提供如下所示的已验证权限策略。

```
permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner
};
```

此策略的评估结果`Action`是`viewSalary`，请求中的资源`ALLOW`是否具有等于委托人的属性所有者。例如，如果 Bob 是请求薪金报告的登录用户，同时也是薪金报告的所有者，则策略的评估结果为。`ALLOW`

以下授权请求已提交给已验证的权限，以供示例策略进行评估。在此示例中，Bob 是`viewSalary`发出请求的登录用户。因此，Bob 是实体类型的主体`Employee`。Bob 正在尝试执行的操作是`viewSalary,`，`viewSalary`将显示的资源`Salary-Bob`与类型相同`Salary`。为了评估 Bob 是否可以查看`Salary-Bob`资源，您需要提供一个实体结构，该结构将值为的类型 `Employee``Bob`（委托人）链接到具有该类型的资源的所有者属性`Salary`。您可以在中提供此结构`entityList`，其中与之关联的属性`Salary`包括所有者，所有者指定`entityIdentifier`包含类型`Employee`和值的`Bob`。Verified Permissions 将授权请求中`principal`提供的权限与与`Salary`资源关联的`owner`属性进行比较，以做出决策。

```
{
  "policyStoreId": "PAYROLLAPP_POLICYSTOREID",
  "principal": {
    "entityType": "PayrollApp::Employee",
    "entityId": "Bob"
  },
  "action": {
    "actionType": "PayrollApp::Action",
    "actionId": "viewSalary"
  },
  "resource": {
    "entityType": "PayrollApp::Salary",
    "entityId": "Salary-Bob"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
          "entityType": "PayrollApp::Salary",
          "entityId": "Salary-Bob"
        },
        "attributes": {
          "owner": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Bob"
            }
          }
        }
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Bob"
        },
        "attributes": {}
      }
    ]
  }
}
```

对已验证权限的授权请求将以下内容作为输出返回，其中属性`decision`为`ALLOW`或`DENY`。

```
{
    "determiningPolicies": 
        [ 
            {
                "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" 
            }
        ],
    "decision": "ALLOW",
    "errors": [] 
}
```

在本例中，由于 Bob 正在尝试查看自己的工资，因此发送给 “已验证权限” 的授权请求计算为`ALLOW`。但是，我们的目标是使用经过验证的权限来强制执行两项业务规则。规定以下内容的业务规则也应为真：

*员工可以查看向他们汇报的任何人的工资。*

为了满足此业务规则，您可以提供其他策略。以下策略评估操作`ALLOW`是否为`viewSalary`，请求中的资源是否具有等`owner.manager`于委托人的属性。例如，如果 Alice 是请求薪资报告的登录用户，而 Alice 是报告所有者的经理，则策略的评估结果为。`ALLOW`

```
permit (
    principal,
    action == Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager
};
```

以下授权请求已提交给已验证的权限，以供示例策略进行评估。在此示例中，Alice 是`viewSalary`发出请求的登录用户。因此，Alice 是委托人，而实体属于这种类型`Employee`。Alice 尝试执行的操作是`viewSalary`，`viewSalary`将显示的资源属于值为`Salary`的类型`Salary-Bob`。为了评估 Alice 能否查看`Salary-Bob`资源，您需要提供一个实体结构，该结构将值为的类型`Employee`链接`Alice`到该`manager`属性，然后该`owner`属性必须与值为的类型的`Salary`属性相关联`Salary-Bob`。您可以在中提供此结构`entityList`，其中与之关联的属性`Salary`包括所有者，所有者指定`entityIdentifier`包含类型`Employee`和值的`Bob`。“已验证权限” 首先检查`owner`属性，该属性将根据类型`Employee`和值`Bob`进行计算。然后，Verified Permissions 会评估`Employee`与之关联的`manager`属性，并将其与提供的委托人进行比较以做出授权决定。在这种情况下，之所以做出决定，`ALLOW`是因为`principal `和`resource.owner.manager`属性是等效的。

```
{
  "policyStoreId": "PAYROLLAPP_POLICYSTOREID",
  "principal": {
    "entityType": "PayrollApp::Employee",
    "entityId": "Alice"
  },
  "action": {
    "actionType": "PayrollApp::Action",
    "actionId": "viewSalary"
  },
  "resource": {
    "entityType": "PayrollApp::Salary",
    "entityId": "Salary-Bob"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Alice"
        },
        "attributes": {
          "manager": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "None"
            }
          }
        },
        "parents": []
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Salary",
          "entityId": "Salary-Bob"
        },
        "attributes": {
          "owner": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Bob"
            }
          }
        },
        "parents": []
      },
      {
        "identifier": {
          "entityType": "PayrollApp::Employee",
          "entityId": "Bob"
        },
        "attributes": {
          "manager": {
            "entityIdentifier": {
              "entityType": "PayrollApp::Employee",
              "entityId": "Alice"
            }
          }
        },
       "parents": []
      }
    ]
  }
}
```

到目前为止，在本示例中，我们提供了与该`viewSalary`方法相关的两个业务规则，*员工可以查看自己的工资*，*员工可以查看向他们汇报的任何人的工资*，将已验证权限作为策略来独立满足每条业务规则的条件。您也可以使用单个 “已验证权限” 策略来满足两个业务规则的条件：

*员工可以查看自己的工资和向他们汇报的任何人的工资。*

当您使用之前的授权请求时，以下策略会评估为操作是`viewSalary`，请求中的资源`ALLOW`是否具有等于的属性 `owner.manager``principal`，还是等于的`principal`属性`owner`。

```
permit (
    principal,
    action == PayrollApp::Action::"viewSalary",
    resource
)
when {
    principal == resource.owner.manager ||
    principal == resource.owner
};
```

例如，如果 Alice 是请求薪资报告的登录用户，如果 Alice 是报告所有者的经理或所有者，则策略的评估结果为。`ALLOW`

有关在 Cedar 策略中使用逻辑运算符的更多信息，请参阅 [Cedar 文档](https://docs.cedarpolicy.com/policies/syntax-operators.html)。