翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
信頼できるトークン発行者によるアプリケーションの使用
信頼できるトークン発行者を使用すると、外部で認証するアプリケーションで信頼できる ID の伝播を使用できます AWS。信頼できるトークン発行者があれば、これらのアプリケーションに、ユーザーに代わって AWS マネージドアプリケーションへのアクセスをリクエストすることを許可できます。
以下のトピックでは、信頼できるトークン発行者の仕組みを説明し、設定ガイダンスを提供します。
信頼できるトークン発行者の概要
信頼できる ID の伝播は、 の外部で認証するアプリケーション AWS が、信頼できるトークン発行者を使用してユーザーに代わってリクエストを実行できるようにするメカニズムを提供します。信頼できるトークン発行者とは、署名付きトークンを作成する OAuth 2.0 認可サーバーです。これらのトークンは、 AWS サービス (受信側アプリケーション) へのアクセス要求 (リクエスト元アプリケーション) を開始するアプリケーションを認可します。リクエスト元アプリケーションは、信頼できるトークン発行者が認証するユーザーに代わってアクセス要求を開始します。ユーザーは、信頼できるトークン発行者と IAM アイデンティティセンターの両方に認識されています。
AWS リクエストを受信する サービスは、Identity Center ディレクトリで表されているように、ユーザーとグループのメンバーシップに基づいてリソースに対するきめ細かな認可を管理します。 AWS サービスは、外部トークン発行者からのトークンを直接使用することはできません。
この問題を解決するために、IAM アイデンティティセンターでは、リクエスト元アプリケーション、またはリクエスト元アプリケーションが使用する AWS ドライバーが、信頼できるトークン発行者が発行したトークンを IAM アイデンティティセンターが生成したトークンと交換する方法を提供しています。IAM アイデンティティセンターによって生成されるトークンは、対応する IAM アイデンティティセンターのユーザーを指します。リクエスト元のアプリケーションまたはドライバーは、新しいトークンを使用して受信側のアプリケーションへのリクエストを開始します。新しいトークンは IAM アイデンティティセンター内の対応するユーザーを参照するため、受信側アプリケーションは IAM アイデンティティセンターに表示されているユーザーまたはグループメンバーシップに基づいて、リクエストされたアクセスを承認できます。
重要
OAuth 2.0 認可サーバーを信頼できるトークン発行者として追加するかどうかは、慎重に検討する必要があるセキュリティ上の決定です。以下のタスクを実行するには、信頼できるトークン発行者のみを選択してください。
-
トークンに指定されているユーザーを認証します。
-
そのユーザーによる受信側のアプリケーションへのアクセスを許可します。
-
IAM アイデンティティセンターが IAM アイデンティティセンターが作成したトークンと交換できるトークンを生成します。
信頼できるトークン発行者の前提条件と考慮事項
信頼できるトークン発行者を設定する前に、次の前提条件と考慮事項を確認します。
-
信頼できるトークン発行者の設定
OAuth 2.0 認可サーバー (信頼できるトークン発行者) を設定する必要があります。信頼されたトークン発行者は、通常、IAM アイデンティティセンターの ID ソースとして使用する ID プロバイダーですが、必ずしもそうである必要はありません。信頼できるトークン発行者を設定する方法については、関連する ID プロバイダーのドキュメントを参照してください。
注記
信頼できるトークン発行者の各ユーザーの ID を IAM アイデンティティセンターの対応するユーザーにマップさえすれば、最大 10 の信頼できるトークン発行者を IAM アイデンティティセンターで使用するように設定できます。
-
トークンを作成する OAuth 2.0 認可サーバー (信頼できるトークン発行者) には、IAM アイデンティティセンターがトークンの署名を検証するためのパブリックキーの取得に使用できる OpenID Connect (OIDC)
ディスカバリーエンドポイントが必要です。詳細については、「OIDC ディスカバリーエンドポイント URL (発行者 URL)」を参照してください。 -
信頼できるトークン発行者が発行するトークン
信頼できるトークン発行者からのトークンは、次の要件を満たす必要があります。
-
トークンは署名済みであり、かつ RS256 アルゴリズムを使用した JSON Web トークン (JWT)
形式である必要があります。 -
トークンには、次のクレームが含まれている必要があります。
-
トークンは、ID トークンでもアクセストークンでもかまいません。
-
トークンには、1 人の IAM アイデンティティセンターユーザーに一意にマッピングできる属性が必要です。
注記
からの JWTsのカスタム署名キーの使用はMicrosoft Entra IDサポートされていません。信頼できるトークン発行Microsoft Entra ID者で のトークンを使用するには、カスタム署名キーを使用できません。
-
-
オプションのクレーム
IAM アイデンティティセンターは RFC 7523 で定義されているすべてのオプションのクレームをサポートしています。詳細については、この RFC の「セクション 3: JWT 形式と処理要件
」を参照してください。 例えば、トークンには JTI (JWT ID) クレーム
を含めることができます。このクレームが存在する場合は、同じ JTI を持つトークンがトークンの交換に再利用されるのを防ぐことができます。JTI クレームの詳細については、「JTI クレームの詳細」を参照してください。 -
信頼できるトークン発行者と連携するための IAM アイデンティティセンターの設定
また、IAM アイデンティティセンターを有効にし、IAM アイデンティティセンターの ID ソースを設定し、信頼できるトークン発行者のディレクトリ内のユーザーに対応するユーザーをプロビジョニングする必要があります。
これを行うには、次のいずれかを実行する必要があります。
-
クロスドメイン ID 管理システム (SCIM) 2.0 プロトコルを使用して、ユーザーを IAM アイデンティティセンターと同期します。
-
IAM アイデンティティセンターでユーザーを直接作成します。
注記
Active Directory ドメイン サービスを ID ソースとして使用する場合、信頼できるトークン発行者はサポートされません。
-
JTI クレームの詳細
IAM アイデンティティセンターが既に交換したトークンを交換するリクエストを IAM アイデンティティセンターが受け取った場合、そのリクエストは失敗します。トークン交換のためのトークンの再利用を検出して防止するために、JTI クレームを含めることができます。IAM アイデンティティセンターは、トークン内のクレームに基づいてトークンの再利用を防止します。
すべての OAuth 2.0 認可サーバーがトークンに JTI クレームを追加するわけではありません。OAuth 2.0 認可サーバーの中には、JTI をカスタムクレームとして追加できないものもあります。JTI クレームの使用をサポートする OAuth 2.0 認可サーバーは、このクレームを ID トークンのみ、アクセストークンのみ、またはその両方に追加する場合があります。詳細については、OAuth 2.0 認可サーバーのドキュメントを参照してください。
トークンを交換するアプリケーションの構築については、IAM アイデンティティセンターAPI ドキュメントを参照してください。正しいトークンを取得して交換するようにカスタマーマネージドアプリケーションを設定する方法については、そのアプリケーションのドキュメントを参照してください。
