翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)。