策略示例

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

主题

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

可用的工具

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

insuranceAPI___get_Policy

检索保单详情。

参数：

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

insuranceAPI___file_Claim

提出保险索赔。

参数：

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

insuranceAPI___update_coverage

更新保单覆盖范围。

参数：

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

insuranceAPI___get_Claim_status

查看索赔状态。

参数：

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

保险 API___计算保费

计算保险费。

参数：

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： Role-based 授权除非

本政策演示了如何使用该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 进行模式匹配

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

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

雪松政策：


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运算符的灵活模式匹配。通配符 * 匹配任何字符，因此 “auto”、“auto-lability”、“综合自动” 或 “自动碰撞” 都将匹配。当你想匹配一类值而不是精确的字符串时，这很有用。

策略 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 逻辑结合在一起。所有三个条件都必须成立：coverageType 必须存在，newLimit 必须存在，CoverageType 必须是 “责任” 或 “碰撞”。这与策略 6 配合使用以创建分层授权：谁可以更新（策略 6）以及他们可以更新什么（策略 8）。

了解授权语义

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

默认拒绝

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

禁止获胜

如果任何禁止政策匹配，即使许可政策也匹配，请求也会被拒绝。如果缺少描述，则策略 5（禁止不带描述）优先于策略 2（有范围的许可）。

策略分层

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

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

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

测试场景

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

场景 1：常规用户查看策略

用户：username= “john”，scope= “insurance: view”

操作：get_pol icy

预期：允许（策略 1）

场景 2：用户提交带有描述的健康声明

用户：username= “jane”，scope= “insurance: claim”

行动：file_claimtype= “健康”，description= “医疗费用”

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

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

用户：username= “jane”，scope= “insurance: claim”

操作：带有 claimType= “健康” 的 file_claim，没有描述

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

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

用户：username= “insurance-agent”，角色= “高级理算师”

行动：使用 cover ageType= “责任” 更新保险范围

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

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

用户：username= “insurance-agent”，role= “agent”

行动：使用 cover ageType= “责任” 更新保险范围

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

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

用户：用户名= “任何人”，scope= “any”

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

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

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"
);

解释：代入角色的 Cedar 实体 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(
  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。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

错误

高级主题