示例 1：具有经过验证的权限和 Cedar 的基本 ABAC

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

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

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

在 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资源，您需要提供一个实体结构，该结构将值为的类型 EmployeeBob（委托人）链接到具有该类型的资源的所有者属性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是否具有等于的属性 principalowner，还是等于的principal属性。owner.manager

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

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

有关在 Cedar 策略中使用逻辑运算符的更多信息，请参阅 Cedar 文档。