ID トークンのマッピングアクセストークンをマッピングするスキーママッピングについて知っておくべきこと

スキーマへの OIDC トークンのマッピング

ID ソースをポリシーストアに追加し、プロバイダークレームまたはトークンをポリシーストアスキーマにマッピングする場合があります。このプロセスを自動化するには、ガイド付きセットアップを使用して ID ソースでポリシーストアを作成するか、ポリシーストアの作成後にスキーマを手動で更新します。トークンをスキーマにマッピングしたら、それらを参照するポリシーを作成できます。

ユーザーガイドのこのセクションには、次の情報が含まれています。

ポリシーストアスキーマに属性を自動的に入力できる場合
ID ソースのスキーマを手動で構築する方法

API リンクポリシーストアとガイド付きセットアップで作成された ID ソースを持つポリシーストアでは、ID (ID) トークン属性をスキーマに手動でマッピングする必要はありません。Verified Permissions にユーザープールの属性を指定し、ユーザー属性が入力されたスキーマを作成できます。ID トークン認可では、Verified Permissions はクレームをプリンシパルエンティティの属性にマッピングします。

Verified Permissions ポリシーストアで OIDC ID プロバイダー (IdP) を ID ソースとして使用するには、スキーマにプロバイダー属性が必要です。スキーマは固定されており、プロバイダートークンが IsAuthorizedWithToken または BatchIsAuthorizedWithToken API リクエストで作成するエンティティに対応している必要があります。ID トークンのプロバイダー情報からスキーマを自動的に入力する方法でポリシーストアを作成した場合は、ポリシーを作成する準備が整います。ID ソースのスキーマなしでポリシーストアを作成する場合は、API リクエストを使用して作成されたエンティティに一致するプロバイダー属性をスキーマに追加する必要があります。その後、プロバイダートークンの属性を使用してポリシーを記述できます。

ID トークンをスキーマにマッピングする

Verified Permissions は、ID トークンクレームをユーザーの名前とタイトル、グループメンバーシップ、連絡先情報などの属性として処理します。ID トークンは、属性ベースのアクセスコントロール (ABAC) 認可モデルで最も役立ちます。Verified Permissions でリクエストを行っているユーザーに基づいてリソースへのアクセスを分析する場合は、ID ソースの ID トークンを選択します。

OIDC プロバイダーの ID トークンの操作は、Amazon Cognito ID トークンの操作とほぼ同じです。違いはクレームにあります。IdP には、標準の OIDC 属性があるか、カスタムスキーマがある場合があります。Verified Permissions コンソールで新しいポリシーストアを作成するときに、ID トークンの例を使用して OIDC ID ソースを追加するか、トークンクレームをユーザー属性に手動でマッピングできます。Verified Permissions は IdP の属性スキーマを認識しないため、この情報を指定する必要があります。

詳細については、「Verified Permissions ポリシーストアの作成」を参照してください。

以下は、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 トークン属性を反映。

アクセストークンをマッピングする

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 スキーマに反映する方法を示しています。スキーマの編集の詳細については、「ポリシーストアスキーマの編集」を参照してください。


{
   "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 アクセストークン属性を反映。

スキーママッピングについて知っておくべきこと

属性マッピングはトークンタイプによって異なります

アクセストークン認可では、Verified Permissions はクレームをコンテキストにマッピングします。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 属性を追加する必要があります。詳細については、「アクセストークンをマッピングする」を参照してください。

OIDC グループのクレームが複数の形式をサポート

OIDC プロバイダーを追加するときは、ポリシーストアのユーザーのグループメンバーシップにマッピングする ID トークンまたはアクセストークンのグループクレームの名前を選択できます。検証済みのアクセス許可は、次の形式でグループのクレームを認識します。

スペースのない文字列: "groups": "MyGroup"
スペース区切りリスト: "groups": "MyGroup1 MyGroup2 MyGroup3"。各文字列はグループです。
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"
      ]
   }
}

このスキーマに対して検証するポリシーの例については、「」を参照してください角括弧表記を使用してトークン属性を参照します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ID ソースの編集

クライアントとオーディエンスの検証