翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# OIDC ID ソースの使用
準拠の OpenID Connect (OIDC) IdP をポリシーストアの ID ソースとして設定することもできます。OIDC プロバイダーは Amazon Cognito ユーザープールに似ています。認証の積として JWTs を生成します。OIDC プロバイダーを追加するには、発行者 URL を指定する必要があります
新しい OIDC ID ソースには、次の情報が必要です。
+ 発行者 URL。Verified Permissions は、この URL で`.well-known/openid-configuration`エンドポイントを検出できる必要があります。
+ ワイルドカードを含まない CNAME レコード。たとえば、 `a.example.com` を にマッピングすることはできません`*.example.net`。逆に、 `*.example.com` を にマッピングすることはできません`a.example.net`。
+ 認可リクエストで使用するトークンタイプ。この場合、**ID トークン**を選択します。
+ ID ソースに関連付けるユーザーエンティティタイプ。例: `MyCorp::User`。
+ ID ソースに関連付けるグループエンティティタイプ。例: `MyCorp::UserGroup`。
+ ID トークンの例、または ID トークン内のクレームの定義。
+ ユーザーおよびグループエンティティ IDs に適用するプレフィックス。CLI と API では、このプレフィックスを選択できます。**API Gateway を使用してセットアップし、ID プロバイダー**または**ガイド付きセットアップ**オプションを使用して作成したポリシーストアでは、Verified Permissions は発行者名から を引いたプレフィックスを割り当てます。たとえば`https://`、 です`MyCorp::User::"auth.example.com|a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"`。
API オペレーションを使用して OIDC ソースからのリクエストを承認する方法の詳細については、「」を参照してください[認可に使用できる API オペレーション](authorization.md#authorization-operations)。
次の例は、経理部門の従業員の年末レポートへのアクセスを許可し、機密分類を持ち、衛星局にいないポリシーを作成する方法を示しています。Verified Permissions は、プリンシパルの 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 Verified Permissions OIDC ID ソースの作成](oidc-create.md)
+ [Amazon Verified Permissions OIDC ID ソースの編集](oidc-edit.md)
+ [OIDC トークンをスキーマにマッピングする](oidc-map-token-to-schema.md)
+ [OIDC プロバイダーのクライアントとオーディエンスの検証](oidc-validation.md)
# Amazon Verified Permissions OIDC ID ソースの作成
次の手順では、ID ソースを既存のポリシーストアに追加します。
Verified Permissions コンソールで[新しいポリシーストアを作成する](policy-stores-create.md)ときに、ID ソースを作成することもできます。このプロセスでは、ID ソーストークンのクレームをエンティティ属性に自動的にインポートできます。**ガイド付きセットアップ**を選択するか、 ** API Gateway と ID プロバイダーオプションを使用してセットアップ**します。これらのオプションでは、初期ポリシーも作成されます。
**注記**
**ID ソース** は、ポリシーストアを作成するまでは左側のナビゲーションペインには表示されません。作成する ID ソースは、現在のポリシーストアに関連付けられます。
Verified Permissions API の [create-identity-source](https://docs.aws.amazon.com/cli/latest/reference/verifiedpermissions/create-identity-source.html) AWS CLI または [CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html) を使用して ID ソースを作成するときに、プリンシパルエンティティタイプを除外できます。ただし、空のエンティティタイプは、エンティティタイプが の ID ソースを作成します`AWS::Cognito`。このエンティティ名は、ポリシーストアスキーマと互換性がありません。 Amazon Cognito ID をポリシーストアスキーマと統合するには、プリンシパルエンティティタイプをサポートされているポリシーストアエンティティに設定する必要があります。
------
#### [ AWS マネジメントコンソール ]
**OpenID Connect (OIDC) ID ソースを作成するには**
1. [Verified Permissions コンソール](https://console.aws.amazon.com/verifiedpermissions/)を開きます。ポリシーストアを選択します。
1. 左側にあるナビゲーションペインで、**[ID ソース]** を選択します。
1. **[ID ソースを作成]**を選択します。
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. **スキーマエンティティへのトークンクレームをマップ**で、ID ソースの**ユーザーエンティティ**と**ユーザークレーム**を選択します。**ユーザーエンティティ**は、OIDC プロバイダーのユーザーを参照するポリシーストア内のエンティティです。**ユーザークレーム**は、通常`sub`、評価対象のエンティティの一意の識別子を保持する ID またはアクセストークンからのクレームです。接続された OIDC IdP の ID は、選択したプリンシパルタイプにマッピングされます。
1. (オプション) **スキーマエンティティへのトークンクレームのマップ**で、アイデンティティソースの**グループエンティティ**と**グループクレーム**を選択します。**グループエンティティ**はユーザー**エンティティ**の[親](https://docs.cedarpolicy.com/overview/terminology.html#term-group)です。グループクレームはこのエンティティにマッピングされます。**グループクレーム**は、評価されるエンティティのユーザーグループ名の文字列、JSON、またはスペースで区切られた文字列を含む ID またはアクセストークン`groups`からのクレームで、通常は です。接続された OIDC IdP の ID は、選択したプリンシパルタイプにマッピングされます。
1. **検証 - オプション**で、ポリシーストアが認可リクエストで受け入れるクライアント IDs またはオーディエンス URLs があれば入力します。
1. **[ID ソースを作成]**を選択します。
1. (オプション) ポリシーストアにスキーマがある場合、Cedar ポリシーのアイデンティティトークンまたはアクセストークンから抽出する属性を参照する前に、スキーマを更新して、ID ソースが作成するプリンシパルのタイプを Cedar に認識させる必要があります。スキーマへの追加には、Cedar ポリシーで参照したい属性を含める必要があります。OIDC トークン属性を Cedar プリンシパル属性にマッピングする方法の詳細については、「」を参照してください[OIDC トークンをスキーマにマッピングする](oidc-map-token-to-schema.md)。
1. トークンからの情報を使用して認可を決定するポリシーを作成します。詳細については、「[Amazon Verified Permissions 静的ポリシーの作成](policies-create.md)」を参照してください。
ID ソースの作成、スキーマの更新、ポリシーの作成が完了したら、 を使用して Verified Permissions `IsAuthorizedWithToken`に認可の決定を依頼します。詳細については、*Amazon Verified Permissions API リファレンスガイド*の[IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)」を参照してください。
------
#### [ AWS CLI ]
**OIDC ID ソースを作成するには**
[CreateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreateIdentitySource.html) オペレーションを使用して ID ソースを作成できます。次の例では、OIDC ID プロバイダー (IdP) から認証された ID にアクセスできる ID ソースを作成します。
1. `create-identity-source` コマンドの `--configuration`パラメータで使用する OIDC IdP の以下の詳細を含む`config.txt`ファイルを作成します。
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["1example23456789"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 次のコマンドを実行して、OIDC ID ソースを作成します。
```
$ 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 ポリシーのアイデンティティトークンまたはアクセストークンから抽出する属性を参照する前に、スキーマを更新して、ID ソースが作成するプリンシパルのタイプを Cedar に認識させる必要があります。スキーマへの追加には、Cedar ポリシーで参照したい属性を含める必要があります。OIDC トークン属性を Cedar プリンシパル属性にマッピングする方法の詳細については、「」を参照してください[OIDC トークンをスキーマにマッピングする](oidc-map-token-to-schema.md)。
1. トークンからの情報を使用して認可を決定するポリシーを作成します。詳細については、「[Amazon Verified Permissions 静的ポリシーの作成](policies-create.md)」を参照してください。
ID ソースの作成、スキーマの更新、ポリシーの作成が完了したら、 を使用して Verified Permissions `IsAuthorizedWithToken`に認可の決定を依頼します。詳細については、*Amazon Verified Permissions API リファレンスガイド*の[IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)」を参照してください。
------
# Amazon Verified Permissions OIDC ID ソースの編集
ID ソースの一部のパラメータは、作成後に編集できます。ID ソースのタイプを変更することはできません。ID ソースを削除し、OIDC または OIDC Amazon Cognito に切り替える新しい ID ソースを作成する必要があります Amazon Cognito。ポリシーストアスキーマが ID ソース属性と一致する場合は、ID ソースに加えた変更を反映するようにスキーマを個別に更新する必要があることに注意してください。
------
#### [ AWS マネジメントコンソール ]
**OIDC ID ソースを更新するには**
1. [Verified Permissions コンソール](https://console.aws.amazon.com/verifiedpermissions/)を開きます。ポリシーストアを選択します。
1. 左側にあるナビゲーションペインで、[**ID ソース**] を選択します。
1. 編集する ID ソースの ID を選択します。
1. **[編集]** を選択します。
1. **OIDC プロバイダーの詳細**で、必要に応じて**発行者 URL** を変更します。
1. **トークンクレームをスキーマ属性にマップ**で、必要に応じてユーザーとグループのクレームとポリシーストアエンティティタイプの関連付けを変更します。エンティティタイプを変更したら、ポリシーとスキーマ属性を更新して、新しいエンティティタイプに適用する必要があります。
1. **対象者の検証**で、適用する対象者値を追加または削除します。
1. **[Save changes]** (変更の保存) をクリックします。
ID ソースを削除するには、ID ソースの横にあるラジオボタンを選択し、次に [**ID ソースを削除**] を選択します。テキストボックスに`delete`を入力し、[**ID ソースを削除**] を選択して ID ソースの削除を確定します。
------
#### [ AWS CLI ]
**OIDC ID ソースを更新するには**
[UpdateIdentitySource](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_UpdateIdentitySource.html) オペレーションを使用して ID ソースを更新できます。次の の例では、指定された ID ソースを更新して、別の OIDC プロバイダーを使用します。
1. `update-identity-source` コマンドの `--configuration`パラメータで使用する OIDC IdP の以下の詳細を含む`config.txt`ファイルを作成します。
```
{
"openIdConnectConfiguration": {
"issuer": "https://auth2.example.com",
"tokenSelection": {
"identityTokenOnly": {
"clientIds":["2example10111213"],
"principalIdClaim": "sub"
},
},
"entityIdPrefix": "MyOIDCProvider",
"groupConfiguration": {
"groupClaim": "groups",
"groupEntityType": "MyCorp::UserGroup"
}
}
}
```
1. 次のコマンドを実行して、OIDC ID ソースを更新します。
```
$ 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"
}
```
**注記**
ID ソースのプリンシパルタイプを変更する場合、更新されたプリンシパルタイプを正しく反映するようにスキーマを更新する必要があります。
------
# OIDC トークンをスキーマにマッピングする
ID ソースをポリシーストアに追加し、プロバイダークレーム、またはトークンをポリシーストアスキーマにマッピングする場合があります。このプロセスを自動化するには、[ガイド付きセットアップ](policy-stores-create.md)を使用して ID ソースでポリシーストアを作成するか、ポリシーストアの作成後にスキーマを手動で更新します。トークンをスキーマにマッピングしたら、それらを参照するポリシーを作成できます。
ユーザーガイドのこのセクションには、次の情報が含まれています。
+ ポリシーストアスキーマに属性を自動的に入力できる場合
+ ID ソースのスキーマを手動で構築する方法
[API リンクポリシーストア](policy-stores-api-userpool.md)と[ガイド付きセットアップ](policy-stores-create.md)で作成された ID ソースを持つポリシーストアでは、ID (ID) トークン属性をスキーマに手動でマッピングする必要はありません。Verified Permissions にユーザープールの属性を指定し、ユーザー属性が入力されたスキーマを作成できます。ID トークン認可では、Verified Permissions はクレームをプリンシパルエンティティの属性にマッピングします。
Verified Permissions ポリシーストアで OIDC ID プロバイダー (IdP) を ID ソースとして使用するには、スキーマにプロバイダー属性が必要です。スキーマは固定されており、プロバイダートークンが [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 トークンのプロバイダー情報からスキーマを自動的に入力する方法でポリシーストアを作成した場合は、ポリシーを作成する準備が整います。ID ソースのスキーマなしでポリシーストアを作成する場合は、API リクエストを使用して作成されたエンティティに一致するプロバイダー属性をスキーマに追加する必要があります。その後、プロバイダートークンの属性を使用してポリシーを記述できます。
**Topics**
+ [ID トークンをスキーマにマッピングする](#oidc-map-id-token)
+ [アクセストークンをマッピングする](#oidc-map-access-token)
+ [スキーママッピングについて知っておくべきこと](#oidc-map-token-to-schema-things-to-know)
## ID トークンをスキーマにマッピングする
Verified Permissions は、ID トークンクレームをユーザーの名前とタイトル、グループメンバーシップ、連絡先情報などの属性として処理します。ID トークンは、*属性ベースのアクセスコントロール* (ABAC) 認可モデルで最も役立ちます。Verified Permissions でリクエストを行っているユーザーに基づいてリソースへのアクセスを分析する場合は、ID ソースの ID トークンを選択します。
OIDC プロバイダーからの ID トークンの操作は、 Amazon Cognito ID トークンの操作とほぼ同じです。違いはクレームにあります。IdP には、[標準の OIDC 属性](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)があるか、カスタムスキーマがある場合があります。Verified Permissions コンソールで新しいポリシーストアを作成するときに、ID トークンの例を使用して OIDC ID ソースを追加するか、トークンクレームをユーザー属性に手動でマッピングできます。Verified Permissions は IdP の属性スキーマを認識しないため、この情報を指定する必要があります。
詳細については、「[Verified Permissions ポリシーストアの作成](policy-stores-create.md)」を参照してください。
以下は、OIDC ID ソースを持つポリシーストアのスキーマの例です。
```
"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 アクセストークンは、Verified Permissions に渡されるとコンテキストオブジェクトにマッピングされます。アクセストークンの属性は `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)。
## スキーママッピングについて知っておくべきこと
**属性マッピングはトークンタイプによって異なります**
アクセストークン認可では、Verified Permissions はクレームを[コンテキスト](context.md)にマッピングします。ID トークン認可では、Verified Permissions はクレームをプリンシパル属性にマッピングします。Verified Permissions コンソールで作成したポリシーストアの場合、**空の**ポリシーストアと**サンプル**ポリシーストアのみが ID ソースを持たず、ID トークン認可のためにユーザープール属性をスキーマに入力する必要があります。アクセストークン認可は、グループメンバークレームを含むロールベースのアクセスコントロール (RBAC) に基づいており、他のクレームをポリシーストアスキーマに自動的にマッピングしません。
**ID ソース属性は必要ありません**
Verified Permissions コンソールで ID ソースを作成すると、必須としてマークされた属性はありません。これにより、クレームの欠落が認可リクエストで検証エラーを引き起こすのを防ぐことができます。必要に応じて属性を に設定できますが、すべての認可リクエストに存在する必要があります。
**RBAC はスキーマに属性を必要としません**
ID ソースのスキーマは、ID ソースを追加するときに作成するエンティティの関連付けによって異なります。ID ソースは、1 つのクレームをユーザーエンティティタイプにマッピングし、1 つのクレームをグループエンティティタイプにマッピングします。これらのエンティティマッピングは、アイデンティティソース設定の中核です。この最小限の情報を使用して、ロールベースのアクセスコントロール (RBAC) モデルで、特定のユーザーおよびユーザーがメンバーである可能性のある特定のグループに対して認可アクションを実行するポリシーを作成できます。スキーマにトークンクレームを追加すると、ポリシーストアの承認範囲が拡張されます。ID トークンのユーザー属性には、属性ベースのアクセスコントロール (ABAC) 認可に貢献できるユーザーに関する情報があります。アクセストークンのコンテキスト属性には、OAuth 2.0 スコープなどの情報があり、プロバイダーからの追加のアクセスコントロール情報を提供できますが、追加のスキーマ変更が必要です。
Verified Permissions コンソール**の API Gateway と ID プロバイダーのセットアップ**と**ガイド付きセットアップ**オプションは、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 は、スペース区切りグループクレームの各文字列を個別のグループとして解釈します。グループ名をスペース文字で 1 つのグループとして解釈するには、クレーム内のスペースを置き換えるか削除します。たとえば、 という名前のグループを `My Group`としてフォーマットします`MyGroup`。
**トークンタイプを選択する**
ポリシーストアが ID ソースと連携する方法は、ID トークンを処理するかアクセストークンを処理するかという ID ソース設定の重要な決定によって異なります。OIDC プロバイダーでは、ID ソースを追加するときにトークンタイプを選択する必要があります。ID トークンまたはアクセストークンを選択できます。選択したトークンタイプは、ポリシーストアで処理されないトークンタイプを除外します。特に、Verified Permissions コンソールの属性への ID トークンクレームの自動マッピングのメリットを享受したい場合は、ID ソースを作成する前に、処理するトークンタイプを早期に決定してください。トークンタイプを変更するには、ポリシーとスキーマをリファクタリングするための多大な労力が必要です。以下のトピックでは、ポリシーストアでの ID トークンとアクセストークンの使用について説明します。
**Cedar パーサーには一部の文字に角括弧が必要です**
ポリシーは通常、 のような形式のスキーマ属性を参照します`principal.username`。トークンクレーム名に表示される`/`可能性がある `:`、、 `.`などのほとんどの英数字以外の文字の場合、Verified Permissions は `principal.cognito:username`や などの条件値を解析できません`context.ip-address`。代わりに`context["ip-address"]`、これらの条件を括弧表記でそれぞれ `principal["cognito:username"]`または の形式でフォーマットする必要があります。アンダースコア文字`_`はクレーム名の有効な文字であり、この要件に対する唯一の英数字以外の例外です。
このタイプのプリンシパル属性のスキーマの部分的な例は、次のようになります。
```
"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 プロバイダーのクライアントとオーディエンスの検証
ID ソースをポリシーストアに追加すると、Verified Permissions には、ID トークンとアクセストークンが意図したとおりに使用されていることを確認する設定オプションがあります。この検証は、 `IsAuthorizedWithToken`および `BatchIsAuthorizedWithToken` API リクエストの処理で行われます。この動作は、ID トークンとアクセストークン、および Amazon Cognito と OIDC ID ソースによって異なります。Amazon Cognito ユーザープールプロバイダーを使用すると、Verified Permissions は ID トークンとアクセストークンの両方でクライアント ID を検証できます。OIDC プロバイダーを使用すると、Verified Permissions は ID トークンのクライアント ID とアクセストークンの対象者を検証できます。
*クライアント ID* は、アプリケーションが使用する ID プロバイダーインスタンスに関連付けられた識別子です`1example23456789`。例: 。*対象者*は、 など、アクセストークンの目的の*証明書利用者*または送信先に関連付けられた URL パスです`https://mytoken.example.com`。アクセストークンを使用する場合、`aud`クレームは常に対象者に関連付けられます。
OIDC ID トークンには、 などのクライアント IDs を含む`aud`クレームがあります`1example23456789`。
OIDC Access トークンには、 などのトークンのオーディエンス URL を含む`aud`クレームと`https://myapplication.example.com`、 などのクライアント IDs を含む`client_id`クレームがあります`1example23456789`。
ポリシーストアを設定するときは、ポリシーストアがトークンの**対象者**を検証するために使用する対象者検証の値を 1 つ以上入力します。
+ **ID トークン** – Verified Permissions は、`aud`クレーム内のクライアント ID の少なくとも 1 つのメンバーが対象者検証値と一致することを確認して、クライアント IDs を検証します。
+ **アクセストークン** – Verified Permissions は、`aud`クレームの URL が対象者検証値と一致することを確認して対象者を検証します。`aud` クレームが存在しない場合、対象者は `cid`または `client_id`クレームを使用して検証できます。ID プロバイダーに正しい対象者のクレームと形式を確認してください。
## JWTs のクライアント側の認可
アプリケーションで JSON ウェブトークンを処理し、ポリシーストア ID ソースを使用せずにそのクレームを Verified Permissions に渡すことができます。JSON Web Token (JWT) からエンティティ属性を抽出し、Verified Permissions に解析できます。
この例では、JWT.1 を使用してアプリケーションから Verified Permissions を呼び出す方法を示します。
```
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) ライブラリを使用して OIDC 互換 IdPs によって署名された JWT を検証しています。