策略示例

本节提供了保险管理系统的 Cedar 授权政策的全面示例。这些示例演示了各种 Cedar 语言功能和授权模式，您可以根据自己的应用程序进行调整。

主题

可用的工具
授权策略
了解授权语义
测试场景
IAM-based 授权示例

可用的工具

保险 API 提供了五种用于管理保险单和索赔的工具：

保险 API___GET_Policy

检索保险单的详细信息。

参数：

policyId（字符串，必填）-策略标识符

保险 API___File_claim

提出保险索赔。

参数：

policyId（字符串，必填）-策略标识符
claimType（字符串，必填）-索赔类型（例如，“健康”、“财产”、“自动”）
amount（数字，必填）-索赔金额
description（字符串，可选）-索赔描述

保险 API___Update_coverage

更新保单覆盖范围。

参数：

policyId（字符串，必填）-策略标识符
coverageType（字符串，必填）-保险类型（例如，“责任”、“碰撞”）
newLimit（数字，必填）-新的承保限额

保险 API___GET_Claim_Status

检查索赔状态。

参数：

claimId（字符串，必填）-索赔标识符

保险 API___calculate_Premium

计算保险费。

参数：

coverageType（字符串，必填）-保险类型
coverageAmount（数字，必填项）-承保金额
riskFactors（对象，可选）-风险评估因素

授权策略

以下政策演示了各种 Cedar 语言功能和授权模式。每项政策都包括自然语言描述、Cedar 代码和详细说明。

政策 1： Multi-action 许可

本政策演示如何使用单个策略声明授予对多个相关操作的访问权限。

自然语言：允许所有委托人获得保单并获得索赔状态。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action in [
    AgentCore::Action::"InsuranceAPI___get_policy",
    AgentCore::Action::"InsuranceAPI___get_claim_status"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
);

说明：本政策演示了使用运营商的多项in操作许可。单个策略授予对多个相关操作的访问权限，而不是为每个读取操作编写单独的策略。这对于对具有相同授权要求的类似操作进行分组很有用。

策略 2： Scope-based 授权

此政策说明如何使用 OAuth 范围来控制对特定操作的访问权限。

自然语言：允许范围包含 “保险：索赔” 的委托人提出索赔。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("scope") &&
  principal.getTag("scope") like "*insurance:claim*"
};

说明：本政策演示了使用标签进行的 OAuth 范围验证。该hasTag方法检查标签是否存在，并getTag检索其值。使用通配like符 (*) 的运算符执行模式匹配，允许灵活的范围格式，例如 “保险:索赔”、“保险:索赔:写入” 或 “管理保险:索赔”。

策略 3：使用 Un Role-based less 进行授权

本政策演示如何使用该unless条款来创建限制例外情况。

自然语言：阻止委托人更新承保范围，除非委托人担任 “高级调整员” 或 “经理” 的角色。

雪松政策：


forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  principal.hasTag("role") &&
  (principal.getTag("role") == "senior-adjuster" || principal.getTag("role") == "manager")
};

解释：该策略演示了该unless条款，该子句颠倒了条件逻辑。除非用户拥有指定角色之一，否则禁令适用。这对于创建限制例外很有用。该策略还显示了用于检查多个可接受值的 OR 逻辑。

策略 4：使用 OR 逻辑实现字符串相等

此策略说明如何验证输入参数以及如何对多个可接受的值使用 OR 逻辑。

自然语言：当索赔类型为健康、财产或汽车时，允许委托人提出索赔。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has claimType &&
  (context.input.claimType == "health" ||
   context.input.claimType == "property" ||
   context.input.claimType == "auto")
};

解释：本政策演示了通过context.input使用 OR 逻辑进行字符串相等性检查来访问工具输入参数。has操作员首先验证字段是否存在，然后再访问该字段，以防止在缺少可选字段时出错。

策略 5：字段存在性检查

此政策演示如何通过要求填写可选字段来强制执行业务规则。

自然语言：除非提供描述，否则禁止委托人提出索赔。

雪松政策：


forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___file_claim",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
unless {
  context.input has description
};

解释：此政策演示如何强制使用可选参数的必填字段。描述字段在工具架构中是可选的，但此政策禁止不包含该字段的请求，从而使其成为必填字段。这显示了策略如何在架构验证之外添加业务规则。

策略 6： Username-based 授权

此政策说明如何根据特定的用户身份授予访问权限。

自然语言：允许用户名为 “Clare” 的校长更新覆盖范围。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "Clare"
};

说明：此政策演示了使用精确字符串匹配进行基于用户名的授权。结合保单3，这创建了由两部分组成的授权：用户必须拥有 “保险代理人” 的用户名并具有 “高级理算师” 或 “经理” 的角色才能更新承保范围。

策略 7：与 like 进行模式匹配

该策略演示了使用通配符进行灵活的模式匹配，以实现基于类别的访问控制。

自然语言：当保险类型包含 “自动” 时，允许委托人计算保费。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___calculate_premium",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input.coverageType like "*auto*"
};

说明：该策略演示了与like运算符的灵活模式匹配。通配符*匹配任何字符，因此 “自动”、“自动责任”、“综合自动” 或 “自动碰撞” 都将匹配。当你想匹配一类值而不是精确的字符串时，这很有用。

策略 8：带有 AND 的组合条件

此策略说明如何组合多个条件来创建复杂的授权规则。

自然语言：当保险类型为责任险或碰撞保险并提供了新的限额时，允许委托人更新承保范围。

雪松政策：


permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"InsuranceAPI___update_coverage",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance"
)
when {
  context.input has coverageType &&
  context.input has newLimit &&
  (context.input.coverageType == "liability" || context.input.coverageType == "collision")
};

说明：此策略演示将多个条件与 AND 逻辑相结合。所有三个条件都必须成立：保险类型必须存在，新限额必须存在，保险类型必须为 “责任” 或 “碰撞”。这与策略 6 配合使用以创建分层授权：谁可以更新（策略 6）以及他们可以更新什么（策略 8）。

了解授权语义

这些策略展示了关键 Cedar 授权语义：

默认拒绝

如果没有任何政策明确允许某项操作，则该操作将被拒绝。例如，即使没有政策明确禁止，没有 “保险：索赔” 范围的用户也无法提出索赔。

禁止获胜

如果任何禁止政策相匹配，则即使许可政策也匹配，该请求也会被拒绝。缺少描述时，策略 5（禁止，但不带描述）将取代策略 2（带范围的许可）。

策略分层

多个策略可以应用于同一个请求：

保单 6 允许保险代理人更新承保范围
策略 3 禁止更新，除非用户具有高级调整员或经理职位
政策 8 仅允许对责任或碰撞类型进行更新

为了使申请成功，它必须满足所有三个条件：成为保险代理人（保单6），担任高级理算师或经理职务（保单3），以及更新责任或碰撞（政策8）。

测试场景

以下情景演示了这些策略在实践中是如何协同工作的：

场景 1：普通用户查看政策

用户：用户名= “约翰”，范围= “保险：查看”

操作：get_policy

预期：允许（策略 1）

场景 2：用户提交带有描述的健康索赔

用户：用户名= “jane”，scope= “保险：索赔”

操作：索赔类型为 “健康” 的 file_claim，description= “医疗费用”

预期：允许（策略 2、策略 4、策略 5 不禁止）

场景 3：用户在没有描述的情况下提出索赔

用户：用户名= “jane”，scope= “保险：索赔”

操作：claimtype= “Health” 的 file_claim，无描述

预期：拒绝（策略 5 禁止获胜）

场景 4：保险代理人更新承保范围

用户：用户名= “保险代理人”，角色= “高级理算师”

行动：使用 coverag eType= “负债” 更新保险

预期：允许（策略 6，策略 3 不禁止，策略 8）

场景 5：没有高级职位的保险代理人

用户：用户名= “保险代理人”，角色= “代理人”

行动：使用 coverag eType= “负债” 更新保险

预期：拒绝（策略 3 禁止获胜）

场景 6：汽车保险的保费计算

用户：用户名= “任何人”，范围= “任意”

操作：使用 coverag eType= “自动赔偿” 计算保费

预期：允许（策略 7，模式匹配 “自动”）

IAM-based 授权示例

当您的 AgentCore 网关使用 AWS_IAM 身份验证而不是 OAuth 时，Cedar 策略中的委托人表示为。AgentCore::IamEntity对于通过假定角色进行身份验证的呼叫者，Cedar 实体 ID 使用该格式arn:aws:sts::<account>:assumed-role/<role-name>，从而实现稳定的principal ==匹配和principal.id模式匹配。

基本 IAM 实体许可证

此政策允许任何 IAM-authenticated 来电者使用特定工具：


permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

解释：这是最简单的 IAM 政策形式。它允许任何通过 AWS_IAM 进行身份验证的呼叫者调用 get_order 工具。当您只需要验证来电者是否 IAM-authenticated 没有其他限制时，请使用此选项。

Role-based 主体精确匹配的限制

使用以下方法限制使用特定 IAM 角色的调用者访问工具：principal ==


permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/MyServiceRole",
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

解释：假定角色的雪松实体 ID 为arn:aws:sts::<account>:assumed-role/<role-name>。无论在身份验证期间使用什么会话名称，这都允许稳定的principal ==匹配。

Role-based 模式匹配的限制

你也可以principal.id like用于更广泛的匹配模式：


permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "arn:aws:sts::111122223333:assumed-role/MyServiceRole"
};

解释：这达到的结果与principal ==但使用了子when句。当你需要更广泛的匹配时，例如匹配账户中的任何角色 (principal.id like "arn:aws:sts::111122223333:assumed-role/*")，模式匹配很有用。

Account-based 限制

限制来自特定 AWS 账户的呼叫者访问工具：


permit(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"OrderAPI___process_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
)
when {
  principal.id like "*:111122223333:*"
};

解释：模式 *: 111122223333: * 与任何包含该账户 ID 的 ARN 相匹配。这仅限制了来自指定 AWS 帐户的呼叫者的访问权限。

Multi-agent 联邦

当具有不同 IAM 角色的多个代理访问同一个网关时，请创建单独的策略来控制每个代理可以使用哪些工具：


// Agent A can only read orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentA-Role",
  action == AgentCore::Action::"OrderAPI___get_order",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

// Agent B can read and process orders
permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/AgentB-Role",
  action in [
    AgentCore::Action::"OrderAPI___get_order",
    AgentCore::Action::"OrderAPI___process_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

说明：此模式对于多代理架构很有用，在这些架构中，不同的代理具有不同的 IAM 角色，应具有不同的工具访问级别。每个策略都principal ==使用特定角色的实体 ID。每个代理的tools/list响应仅包括他们有权使用的工具。

带输入验证功能的 IAM

将 IAM 主体匹配与工具输入验证相结合：


permit(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/RefundProcessorRole",
  action == AgentCore::Action::"RefundAPI___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  context.input has amount &&
  context.input.amount < 1000
};

解释：此策略将精确的主体匹配与输入验证相结合。只有假设RefundProcessorRole来自指定账户的来电者才能处理退款，并且只有在退款金额低于1000美元时才能处理退款。

禁止特定账户

阻止来自特定 AWS 账户的来电者访问敏感工具：


forbid(
  principal is AgentCore::IamEntity,
  action == AgentCore::Action::"AdminAPI___delete_resource",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/admin-gateway"
)
when {
  principal.id like "*:444455556666:*"
};

解释：此禁止政策禁止来自第三方供应商账户 (444455556666) 的所有来电者执行管理删除。由于 forbid-wins 语义，这优先于任何许可策略。

禁止特定角色执行敏感操作

阻止使用只读角色的呼叫者执行写入操作：


forbid(
  principal == AgentCore::IamEntity::"arn:aws:sts::111122223333:assumed-role/ReadOnlyAgentRole",
  action in [
    AgentCore::Action::"OrderAPI___process_order",
    AgentCore::Action::"OrderAPI___cancel_order"
  ],
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/order-gateway"
);

解释：此禁止策略可防止使用调用者ReadOnlyAgentRole执行写入操作，无论是否有任何允许的许可策略。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

错误

高级主题