本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 使用 OIDC 身份来源
您也可以将任何合规的 OpenID Connect (OIDC) IdP 配置为策略存储的身份源。OIDC 提供商与 Amazon Cognito 用户池类似：它们是作为身份验证的 JWTs 产物生成的。要添加 OIDC 提供商，您必须提供颁发机构 URL
新的 OIDC 身份源需要以下信息：
+ 发行人网址。经过验证的权限必须能够在此 URL 上发现`.well-known/openid-configuration`终端节点。
+ 不包含通配符的 CNAME 记录。例如，`a.example.com`无法映射到`*.example.net`。相反，`*.example.com`无法映射到。`a.example.net`
+ 您要在授权请求中使用的令牌类型。在本例中，您选择了**身份令牌**。
+ 例如，您要与身份源关联的用户实体类型`MyCorp::User`。
+ 例如，您要与身份源关联的群组实体类型`MyCorp::UserGroup`。
+ ID 令牌示例，或 ID 令牌中声明的定义。
+ 要应用于用户和群组实体的前缀 IDs。在 CLI 和 API 中，您可以选择此前缀。例如`MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`，在您使用 “使用 **API Gateway 和身份提供者进行设置**” 或 “**引导式设置**” 选项创建的策略存储中，Verified Permissions 会分配颁发者名称减去`https://`的前缀。
有关使用 API 操作授权来自 OIDC 来源的请求的更多信息，请参阅。[可用于授权的 API 操作](authorization.md#authorization-operations)
以下示例说明如何创建允许会计部门员工访问年终报告的策略，该策略具有机密分类且不在卫星办公室的员工可以访问年终报告。已验证权限从委托人 ID 令牌中的声明中派生这些属性。
请注意，在委托人中引用组时，必须使用`in`运算符才能正确评估策略。
```
permit(
principal in MyCorp::UserGroup::"MyOIDCProvider|Accounting",
action,
resource in MyCorp::Folder::"YearEnd2024"
) when {
principal.jobClassification == "Confidential" &&
!(principal.location like "SatelliteOffice*")
};
```
**Topics**
+ [创建 Amazon 已验证权限 OIDC 身份源](oidc-create.md)
+ [编辑 Amazon 已验证权限 OIDC 身份源](oidc-edit.md)
+ [将 OIDC 令牌映射到架构](oidc-map-token-to-schema.md)
+ [OIDC 提供商的客户和受众验证](oidc-validation.md)
# 创建 Amazon 已验证权限 OIDC 身份源
以下过程将身份源添加到现有策略存储中。
在已验证权限控制台中[创建新的策略存储](policy-stores-create.md)时，您也可以创建身份源。在此过程中，您可以自动将身份源令牌中的声明导入实体属性中。选择 “引**导式设置”** 或 “**设置方式” API Gateway 和 “身份提供商**” 选项。这些选项还会创建初始策略。
**注意**
在您创建策略存储之前，左侧的导航窗格中不会显示**身份来源**。您创建的身份来源与当前的策略存储相关联。
使用 AWS CLI 或[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)在已验证权限 API [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html)中创建身份源时，可以省略委托人实体类型。但是，空白实体类型会创建实体类型为的身份源`AWS::Cognito`。此实体名称与策略存储架构不兼容。要将 Amazon Cognito 身份与策略存储架构集成，必须将委托人实体类型设置为支持的策略存储实体。
------
#### [ AWS 管理控制台 ]
**创建 OpenID Connect (OIDC) 身份源**
1. 打开已[验证权限控制台](https://console.aws.amazon.com/verifiedpermissions/)。选择您的保单商店。
1. 在左侧的导航窗格中，选择**身份来源**。
1. 选择**创建身份来源**。
1. 选择**外部 OIDC** 提供商。
1. 在**发卡机构 URL 中，输入您的 OIDC 发行**人的 URL。例如，这是提供授权服务器、签名密钥以及有关您的提供商的其他信息的服务端点`https://auth.example.com`。您的发卡机构 URL 必须托管 OIDC 发现文档，网址为。`/.well-known/openid-configuration`
1. 在**令牌类型**中，选择您希望您的应用程序提交以进行授权的 OIDC JWT 类型。有关更多信息，请参阅 [将 OIDC 令牌映射到架构](oidc-map-token-to-schema.md)。
1. 在将**令牌声明映射到架构实体**中，为身份源选择**用户实体****和用户声明**。**用户实体**是您的策略存储中的一个实体，您想要引用来自 OIDC 提供商的用户。**用户声明**通常`sub`是来自您的身份证或访问令牌的索赔，该令牌包含待评估实体的唯一标识符。来自连接的 OIDC IdP 的身份将映射到选定的主体类型。
1. （可选）在 “将**令牌声明映射到架构实**体” 中，为身份源选择**群**组实体**和群组声明**。**组实体**是**用户实体的[父](https://docs.cedarpolicy.com/overview/terminology.html#term-group)实体**。团体索赔将映射到该实体。**群组声明**通常是来自您的 ID 或访问令牌的声明`groups`，其中包含要评估的实体的字符串、JSON 或以空格分隔的用户组名称字符串。来自连接的 OIDC IdP 的身份将映射到选定的主体类型。
1. 在 “**验证-可选**” 中，输入您 URLs 希望您的策略商店在授权请求中接受的客户 IDs 或受众（如果有）。
1. 选择**创建身份来源**。
1. （可选）如果您的策略存储具有架构，则必须先更新架构，让 Cedar 知道您的身份源创建的主体类型，然后才能引用从 Cedar 策略中的身份或访问令牌中提取的属性。架构中的新增内容必须包含您要在 Cedar 策略中引用的属性。有关将 OIDC 代币属性映射到 Cedar 主体属性的更多信息，请参阅。[将 OIDC 令牌映射到架构](oidc-map-token-to-schema.md)
1. 创建使用令牌中的信息做出授权决策的策略。有关更多信息，请参阅 [创建 Amazon Verified Permissions 静态策略](policies-create.md)。
现在，您已经创建了身份源、更新了架构并创建了策略，请使用已验证的权限`IsAuthorizedWithToken`来做出授权决定。有关更多信息，请参阅 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)*Amazon 已验证权限 API 参考指南*。
------
#### [ AWS CLI ]
**创建 OIDC 身份源**
您可以使用[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html)操作创建身份源。以下示例创建了可以从 OIDC 身份提供商 (IdP) 访问经过身份验证的身份的身份源。
1. 创建一个包含 OIDC IdP 以下详细信息的`config.txt`文件，供命令的`--configuration`参数使用。`create-identity-source`
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["1example23456789"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 运行以下命令创建 OIDC 身份源。
```
$ aws verifiedpermissions create-identity-source \
--configuration file://config.txt \
--principal-entity-type "User" \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
1. （可选）如果您的策略存储具有架构，则必须先更新架构，让 Cedar 知道您的身份源创建的主体类型，然后才能引用从 Cedar 策略中的身份或访问令牌中提取的属性。架构中的新增内容必须包含您要在 Cedar 策略中引用的属性。有关将 OIDC 代币属性映射到 Cedar 主体属性的更多信息，请参阅。[将 OIDC 令牌映射到架构](oidc-map-token-to-schema.md)
1. 创建使用令牌中的信息做出授权决策的策略。有关更多信息，请参阅 [创建 Amazon Verified Permissions 静态策略](policies-create.md)。
现在，您已经创建了身份源、更新了架构并创建了策略，请使用已验证的权限`IsAuthorizedWithToken`来做出授权决定。有关更多信息，请参阅 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)*Amazon 已验证权限 API 参考指南*。
------
# 编辑 Amazon 已验证权限 OIDC 身份源
创建身份源后，您可以编辑身份源的某些参数。您无法更改身份源的类型，必须删除身份源并创建一个新的身份源以从 OIDC 或 OIDC 切换 Amazon Cognito 到。 Amazon Cognito如果您的策略存储架构与您的身份源属性相匹配，则请注意，您必须单独更新架构以反映您对身份源所做的更改。
------
#### [ AWS 管理控制台 ]
**更新 OIDC 身份源**
1. 打开已[验证权限控制台](https://console.aws.amazon.com/verifiedpermissions/)。选择您的保单商店。
1. 在左侧的导航窗格中，选择**身份来源**。
1. 选择要编辑的身份来源的 ID。
1. 选择**编辑**。
1. 在 **OIDC 提供商详细信息**中，根据需要更改**发行者 URL**。
1. 在将**令牌声明映射到架构属性**中，根据需要更改用户和组声明与策略存储实体类型之间的关联。更改实体类型后，必须更新策略和架构属性以应用于新的实体类型。
1. 在**受众验证**中，添加或删除要强制执行的受众群体值。
1. 选择**保存更改**。
如要删除身份来源，您可以选择身份来源旁边的单选按钮，然后选择**删除身份来源**。在文本框中输入 `delete`，然后选择**删除身份来源**，确认删除该身份来源。
------
#### [ AWS CLI ]
**更新 OIDC 身份源**
您可以使用[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html)操作更新身份源。以下示例将指定的身份源更新为使用其他 OIDC 提供商。
1. 创建一个包含 OIDC IdP 以下详细信息的`config.txt`文件，供命令的`--configuration`参数使用。`update-identity-source`
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth2.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["2example10111213"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 运行以下命令更新 OIDC 身份源。
```
$ aws verifiedpermissions update-identity-source \
--update-configuration file://config.txt \
--policy-store-id 123456789012
{
"createdDate": "2023-05-19T20:30:28.214829+00:00",
"identitySourceId": "ISEXAMPLEabcdefg111111",
"lastUpdatedDate": "2023-05-19T20:30:28.214829+00:00",
"policyStoreId": "PSEXAMPLEabcdefg111111"
}
```
**注意**
如果要更改该身份来源的主体类型，必须更新架构，以正确反映更新后的主体类型。
------
# 将 OIDC 令牌映射到架构
您可能会发现想要将身份源添加到策略存储中，并将地图提供商声明或令牌添加到策略存储架构中。您可以自动执行此过程，方法是使用[引导式设置](policy-stores-create.md)创建带有身份源的策略存储，或者在创建策略存储后手动更新架构。将令牌映射到架构后，您可以创建引用它们的策略。
用户指南的这一部分包含以下信息：
+ 何时可以自动填充策略存储架构的属性
+ 如何为身份源手动构建架构
通过[引导式设置](policy-stores-create.md)创建的 [API 关联策略存储](policy-stores-api-userpool.md)和带有身份源的策略存储不需要将身份 (ID) 令牌属性手动映射到架构。您可以为用户池中的属性提供经过验证的权限，并创建填充用户属性的架构。在 ID 令牌授权中，已验证权限将声明映射到委托人实体的属性。
要使用 OIDC 身份提供商 (IdP) 作为已验证权限策略存储中的身份源，您的架构中必须包含提供者属性。架构是固定的，必须与提供者令牌创建的实体[IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)或 [BatchIsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_BatchIsAuthorizedWithToken.html)API 请求相对应。如果您创建策略存储的方式是自动从 ID 令牌中的提供者信息填充架构，那么您就可以编写策略了。如果您创建的策略存储没有身份源架构，则必须向架构中添加与使用 API 请求创建的实体相匹配的提供者属性。然后，您可以使用提供者令牌中的属性来编写策略。
**Topics**
+ [将 ID 令牌映射到架构](#oidc-map-id-token)
+ [映射访问令牌](#oidc-map-access-token)
+ [关于架构映射的注意事项](#oidc-map-token-to-schema-things-to-know)
## 将 ID 令牌映射到架构
Verified Permissions 将身份令牌声明作为用户的属性进行处理：他们的姓名和头衔、群组成员资格、联系信息。ID 令牌在*基于属性的访问控制* (ABAC) 授权模型中最有用。如果您想让经过验证的权限根据谁提出请求来分析对资源的访问权限，请为您的身份来源选择 ID 令牌。
使用 OIDC 提供商提供的 ID 令牌与使用 Amazon Cognito ID 令牌大致相同。区别在于索赔。您的 IdP 可能呈现[标准的 OIDC 属性](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)，或者具有自定义架构。在已验证权限控制台中创建新的策略存储时，可以添加带有示例 ID 令牌的 OIDC 身份源，也可以手动将令牌声明映射到用户属性。由于已验证权限不知道您的 IdP 的属性架构，因此您必须提供此信息。
有关更多信息，请参阅 [创建 Verified Permissions 策略存储](policy-stores-create.md)。
以下是具有 OIDC 身份源的策略存储的示例架构。
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"email": {
"type": "String"
},
"email_verified": {
"type": "Boolean"
},
"name": {
"type": "String",
"required": true
},
"phone_number": {
"type": "String"
},
"phone_number_verified": {
"type": "Boolean"
}
}
}
}
```
有关将针对此架构进行验证的策略示例，请参阅[反映 OIDC ID 令牌属性](policies-examples.md#policies-examples-oidc-id)。
## 映射访问令牌
Verified Permissions 处理除组声明之外的访问令牌声明作为操作属性或*上下文*属性。除了群组成员资格外，来自您的 IdP 的访问令牌可能还包含有关 API 访问的信息。访问令牌在使用基于角色的访问控制 (RBAC) 的授权模型中很有用。依赖组成员资格以外的访问令牌声明的授权模型需要在架构配置方面付出额外的努力。
来自外部 OIDC 提供商的大多数访问令牌都与 Amazon Cognito 访问令牌非常一致。传递给 “已验证权限” 时，OIDC 访问令牌会映射到上下文对象。可以使用 `context.token.attribute_name` 来引用访问令牌的属性。以下示例 OIDC 访问令牌包括基本声明示例。
```
{
"sub": "91eb4550-9091-708c-a7a6-9758ef8b6b1e",
"groups": [
"Store-Owner-Role",
"Customer"
],
"iss": "https://auth.example.com",
"client_id": "1example23456789",
"aud": "https://myapplication.example.com"
"scope": "MyAPI-Read",
"exp": 1688096566,
"iat": 1688092966,
"jti": "a1b2c3d4-e5f6-a1b2-c3d4-TOKEN2222222",
"username": "alice"
}
```
以下示例说明了如何在 Verified Permissions 架构中反映示例访问令牌中的属性。有关编辑架构的更多信息，请参阅[编辑策略存储架构](schema-edit.md)。
```
{
"MyApplication": {
"actions": {
"Read": {
"appliesTo": {
"context": {
"type": "ReusedContext"
},
"resourceTypes": [
"Application"
],
"principalTypes": [
"User"
]
}
}
},
...
...
"commonTypes": {
"ReusedContext": {
"attributes": {
"token": {
"type": "Record",
"attributes": {
"scope": {
"type": "Set",
"element": {
"type": "String"
}
},
"client_id": {
"type": "String"
}
}
}
},
"type": "Record"
}
}
}
}
```
有关将针对此架构进行验证的策略示例，请参阅[反映 OIDC 访问令牌属性](policies-examples.md#policies-examples-oidc-access)。
## 关于架构映射的注意事项
**不同标记类型的属性映射不同**
在访问令牌授权中，已验证权限将声明映射到[上下文](context.md)。在 ID 令牌授权中，已验证权限将声明映射到委托人属性。对于您在已验证权限控制台中创建的策略存储，只有**空**策略存储和**示例**策略存储才会使您没有身份来源，并要求您在架构中填充用户池属性以进行 ID 令牌授权。访问令牌授权基于基于角色的访问控制 (RBAC) 和群组成员资格声明，不会自动将其他声明映射到策略存储架构。
**不需要身份源属性**
在已验证权限控制台中创建身份源时，不会将任何属性标记为必填属性。这样可以防止丢失的索赔导致授权请求中的验证错误。您可以根据需要将属性设置为 required，但它们必须存在于所有授权请求中。
**RBAC 不需要架构中的属性**
身份源的架构取决于您在添加身份源时建立的实体关联。身份源将一个声明映射到用户实体类型，将一个声明映射到群组实体类型。这些实体映射是身份源配置的核心。有了这些最少的信息，您就可以在基于角色的访问控制 (RBAC) 模型中编写对特定用户和用户可能属于的特定组执行授权操作的策略。向架构中添加令牌声明可扩展策略存储的授权范围。来自 ID 令牌的用户属性包含可以为基于属性的访问控制 (ABAC) 授权做出贡献的用户信息。访问令牌的上下文属性包含诸如 OAuth 2.0 作用域之类的信息，这些信息可以提供来自提供者的额外访问控制信息，但需要进行额外的架构修改。
已验证权限控制台中的 “**使用 API Gateway 和身份提供者****进行设置” 和 “引导式设置**” 选项为架构分配 ID 令牌声明。访问令牌声明的情况并非如此。[要向架构中添加非组访问令牌声明，必须在 JSON 模式下编辑架构并添加 CommonTypes 属性。](https://docs.cedarpolicy.com/schema/json-schema.html#schema-commonTypes)有关更多信息，请参阅 [映射访问令牌](#oidc-map-access-token)。
**OIDC 团体声称支持多种格式**
添加 OIDC 提供商时，您可以在 ID 或访问令牌中选择要映射到策略存储中用户的群组成员资格的群组名称。经过验证的权限可以识别以下格式的群组声明：
1. 不带空格的字符串：`"groups": "MyGroup"`
1. 以空格分隔的列表:. `"groups": "MyGroup1 MyGroup2 MyGroup3"` 每个字符串都是一个组。
1. JSON（以逗号分隔）列表：`"groups": ["MyGroup1", "MyGroup2", "MyGroup3"]`
**注意**
Verified Permissions 将以空格分隔的群组声明中的每个字符串解释为一个单独的群组。要将带有空格字符的组名解释为单个组，请替换或删除声明中的空格。例如，设置名为的群组`My Group`的格式`MyGroup`。
**选择代币类型**
您的策略存储与身份源配合的方式取决于身份源配置中的一个关键决定：是处理 ID 还是访问令牌。对于 OIDC 提供商，您必须在添加身份源时选择令牌类型。您可以选择 ID 或访问令牌，并且您的选择会将未选择的令牌类型排除在保单存储库中的处理范围之外。特别是如果您希望从身份令牌声明自动映射到已验证权限控制台中的属性中受益，请在创建身份源之前尽早决定要处理的令牌类型。更改令牌类型需要花费大量精力来重构您的策略和架构。以下主题介绍如何在策略存储中使用 ID 和访问令牌。
**Cedar 解析器要求某些字符使用方括号**
策略通常以类似的格式引用架构属性`principal.username`。对于令牌声明名称中可能出现的大多数非字母数字字符`:`，例如`.`、或`/`，Verified Permissions 无法解析像或这样的条件值。`principal.cognito:username` `context.ip-address`您必须改为使用`principal["cognito:username"]`或`context["ip-address"]`格式的方括号表示法来格式化这些条件。下划线字符`_`是声明名称中的有效字符，也是该要求的唯一非字母数字例外。
此类型主属性的部分示例架构如下所示：
```
"User": {
"shape": {
"type": "Record",
"attributes": {
"cognito:username": {
"type": "String",
"required": true
},
"custom:employmentStoreCode": {
"type": "String",
"required": true,
},
"email": {
"type": "String",
"required": false
}
}
}
}
```
这种类型的上下文属性的部分示例架构如下所示：
```
"GetOrder": {
"memberOf": [],
"appliesTo": {
"resourceTypes": [
"Order"
],
"context": {
"type": "Record",
"attributes": {
"ip-address": {
"required": false,
"type": "String"
}
}
},
"principalTypes": [
"User"
]
}
}
```
有关将针对此架构进行验证的策略示例，请参阅[使用方括号表示法来引用代币属性](policies-examples.md#policies-examples-brackets)。
# OIDC 提供商的客户和受众验证
向策略存储中添加身份源时，Verified Permissions 具有用于验证 ID 和访问令牌是否按预期使用的配置选项。这种验证发生在 `BatchIsAuthorizedWithToken` API 请求`IsAuthorizedWithToken`的处理过程中。ID 和访问令牌以及 Amazon Cognito 和 OIDC 身份源的行为有所不同。通过 Amazon Cognito 用户池提供商，经过验证的权限可以验证身份和访问令牌中的客户端 ID。通过 OIDC 提供商，经过验证的权限可以验证 ID 令牌中的客户端 ID 和访问令牌中的受众。
例如，*客户端 ID* 是与您的应用程序使用的身份提供商实例关联的标识符`1example23456789`。例如，*受众*是与访问令牌的预期*依赖方*或目标相关联的 URL 路径`https://mytoken.example.com`。使用访问令牌时，`aud`声明始终与受众相关联。
OIDC ID 令牌的`aud`声明包含客户端 IDs，例如。`1example23456789`
OIDC 访问令牌的`aud`声明包含令牌的受众网址（例如`https://myapplication.example.com`）和包含客户端 IDs（例如）的`client_id`声明。`1example23456789`
设置策略存储时，请输入一个或多个**受众验证**值，您的政策存储使用该值来验证令牌的受众。
+ **ID 令牌** — 已验证权限通过检查`aud`声明 IDs 中至少有一名客户成员与受众验证值匹配来验证客户端 ID。
+ **访问令牌** — 已验证权限通过检查`aud`声明中的网址是否与受众验证值相匹配来验证受众。如果不存在任何`aud`声明，则可以使用`cid`或`client_id`声明来验证受众。请咨询您的身份提供商，了解正确的受众主张和格式。
## 的客户端授权 JWTs
您可能需要在应用程序中处理 JSON Web 令牌并将其声明传递给已验证权限，而无需使用策略存储标识源。您可以从 JSON Web 令牌 (JWT) 中提取实体属性并将其解析为已验证的权限。
此示例说明如何使用 JWT 从应用程序调用 “已验证权限”。¹
```
async function authorizeUsingJwtToken(jwtToken) {
const payload = await verifier.verify(jwtToken);
let principalEntity = {
entityType: "PhotoFlash::User", // the application needs to fill in the relevant user type
entityId: payload["sub"], // the application need to use the claim that represents the user-id
};
let resourceEntity = {
entityType: "PhotoFlash::Photo", //the application needs to fill in the relevant resource type
entityId: "jane_photo_123.jpg", // the application needs to fill in the relevant resource id
};
let action = {
actionType: "PhotoFlash::Action", //the application needs to fill in the relevant action id
actionId: "GetPhoto", //the application needs to fill in the relevant action type
};
let entities = {
entityList: [],
};
entities.entityList.push(...getUserEntitiesFromToken(payload));
let policyStoreId = "PSEXAMPLEabcdefg111111"; // set your own policy store id
const authResult = await client
.isAuthorized({
policyStoreId: policyStoreId,
principal: principalEntity,
resource: resourceEntity,
action: action,
entities,
})
.promise();
return authResult;
}
function getUserEntitiesFromToken(payload) {
let attributes = {};
let claimsNotPassedInEntities = ['aud', 'sub', 'exp', 'jti', 'iss'];
Object.entries(payload).forEach(([key, value]) => {
if (claimsNotPassedInEntities.includes(key)) {
return;
}
if (Array.isArray(value)) {
var attibuteItem = [];
value.forEach((item) => {
attibuteItem.push({
string: item,
});
});
attributes[key] = {
set: attibuteItem,
};
} else if (typeof value === 'string') {
attributes[key] = {
string: value,
}
} else if (typeof value === 'bigint' || typeof value ==='number') {
attributes[key] = {
long: value,
}
} else if (typeof value === 'boolean') {
attributes[key] = {
boolean: value,
}
}
});
let entityItem = {
attributes: attributes,
identifier: {
entityType: "PhotoFlash::User",
entityId: payload["sub"], // the application needs to use the claim that represents the user-id
}
};
return [entityItem];
}
```
¹ 此代码示例使用该[aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)库来验证由 OID IdPs C JWTs 兼容的签名。