IDフェデレーション（SAML 2.0）難易度 標準無料
従業員500名の企業が、社内のオンプレミスActive Directory（AD FSでSAML 2.0対応済み）を使って、AWSマネジメントコンソールへのシングルサインオンを実現したい。従業員ごとにIAMユーザーを作成することは避けたい。この要件を満たす設計として最も適切なものを選べ。（単一選択）
- AIAMにSAML 2.0のIDプロバイダーとしてAD FSを登録し、そのIdPを信頼するIAMロールを作成する。従業員はAD FSで認証後、発行されたSAMLアサーションを使ってロールを引き受け、一時的なAWS認証情報でコンソールにサインインする
- B従業員500名分のIAMユーザーを作成し、ADのグループに合わせてIAMグループへ割り当てる。パスワードはAD側と別に管理する
- CAWSアカウントのルートユーザーの認証情報を複数の従業員で共有し、AD FSでの認証後にその認証情報を使わせる
- DCognitoユーザープールを作成し、SAMLのIdPとしてAD FSを連携させ、コンソールへのサインインをCognito経由にする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
オンプレミスの既存IdP（AD FS等）を使ってAWSコンソールへフェデレーションする標準パターンは、 IAMで SAML 2.0 のIDプロバイダー（IdP）をアイデンティティプロバイダーとして登録し、 そのIdPを信頼するIAMロールを作成することである。
- 従業員はまず社内のAD FSで認証し、AD FSがSAMLアサーションを生成する。
- そのSAMLアサーションをAWSのサインインエンドポイント（
https://signin.aws.amazon.com/saml）へPOSTすると、 STSのAssumeRoleWithSAML相当の処理でロールが引き受けられ、一時的なAWS認証情報が発行されてコンソールにサインインできる。 - ロールにアタッチする権限ポリシーで、部門やAD上のグループに応じた権限をマッピングできる。
これにより500名分のIAMユーザーを作成せず、既存のADによる認証基盤をそのままAWSコンソールアクセスの認証に使い回せる。
- B避けたいとされている「従業員ごとにIAMユーザーを作成する」設計そのもの。ID管理が二重化しSSOにもならない。
- Cルートユーザーの共有は最も避けるべきプラクティス。権限の分離・監査ができず、フェデレーションの仕組みでもない。
- DCognitoユーザープールは主に自社アプリケーションのエンドユーザー認証向けの機能。企業の従業員をAWSコンソールへフェデレーションする標準手段はIAM SAML IDプロバイダー＋ロールであり、Cognitoが必須ではない。
ひっかけ： 「従業員ごとにIAMユーザーを作る（B）」は今回避けたい設計そのもの。「Cognitoユーザープールを使う（D）」は
アプリケーション（自社サービス）のエンドユーザー認証に向く機能であり、社内ADと連携した企業内コンソールアクセスのSSOにはIAM ID プロバイダー＋ロールが本筋である点を区別する。
公式ドキュメント・関連IAM User Guide ― Creating IAM SAML identity providers↗IAM User Guide ― About SAML 2.0-based federation↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）