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

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

此示例使用已验证的权限和 Cedar 来演示基本的 RBAC。如前所述，Cedar的基本结构是一个实体。开发人员定义自己的实体，并且可以选择在实体之间创建关系。以下示例包括三种类型的实体：`Users``Roles`、和`Problems`。 `Students`并且`Teachers`可以被视为该类型的实体`Role,`，每个实体`User`都可以与零或任何一个相关联`Roles`。

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


在 Cedar 中，这些关系是通过将链接`Role``Student`到`User``Bob`作为其父项来表达的。这种关联在逻辑上将所有学生用户分组到一个组中。有关在 Cedar 中进行分组的更多信息，请参阅 [Cedar 文档](https://docs.cedarpolicy.com/overview/terminology.html#term-group)。

以下策略评估与该类型的逻辑组相关联的所有委托`Students`人的操作`submitProblem,`决策`ALLOW`。`Role`

```
permit (
    principal in ElearningApp::Role::"Students",
    action == ElearningApp::Action::"submitProblem",
    resource
);
```

以下策略根据操作的决策进行评估`answerProblem`，`submitProblem`或者`ALLOW`针对与该类型的逻辑组相关联的所有委托`Teachers`人进行评估。`Role`

```
permit (
    principal in ElearningApp::Role::"Teachers",
    action in [
        ElearningApp::Action::"submitProblem",
        ElearningApp::Action::"answerProblem"
    ],
    resource
);
```

为了评估使用这些策略的请求，评估引擎需要知道授权请求中引用的委托人是否为相应组的成员。因此，应用程序必须将相关的群组成员资格信息作为授权请求的一部分传递给评估引擎。这是通过属性完成的，它使您能够向 Cedar 评估引擎提供授权调用中涉及的委托人和资源的属性和组成员身份数据。`entities`在以下代码中，组成员资格通过定义`User::"Bob"`为调用父代来表示`Role::"Students"`。

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Bob"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Bob"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Students"
                } 
            ]
        },
        {
          "identifier": {
            "entityType": "ElearningApp::Problem",
            "entityId": "SomeProblem"
          },
          "attributes": {},
          "parents": []
        }
      ]
  }
}
```

在此示例中，Bob 是`answerProblem`发出请求的登录用户。因此，Bob 是委托人，而实体属于该类型`User`。Bob 想要执行的操作是`answerProblem`。为了评估 Bob 能否执行`answerProblem`操作，您需要提供一个实体结构，该结构将该实体`User`与值关联起来，`Bob`并通过将父实体列为`Role::"Students"`，来分配其组成员资格。由于用户组`Role::"Students"`中的实体只能执行操作，因此此授权请求的计算结果为。`submitProblem` `DENY`

另一方面，如果值为`Alice`且属于该组的类型`User``Role::"Teachers"`尝试执行操作，则授权请求的计算结果为`ALLOW`，因为该策略规定允许组中的委托人对`Role::"Teachers"`所有资源执行操作。`answerProblem` `answerProblem`以下代码显示了评估结果为的此类授权请求。`ALLOW`

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Alice"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Alice"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Teachers"
                } 
            ]
        },
        {
            "identifier": {
                "entityType": "ElearningApp::Problem",
                "entityId": "SomeProblem"
            },
            "attributes": {},
            "parents": []
        }
      ]
  }
}
```