先日、Entra ID と AWS IAM Identity Center を SAML 連携し シングルサインオン (SSO) する検証をしました！
今回検証にて実装した構成は以下です：
| - | 構成 |
|---|---|
| IdP (Identity Provider) | Microsoft Entra ID |
| SP (Service Provider) | AWS IAM Identity Center |
| ユーザープロビジョニング | 手動 (既定) |
| SSO 認証方式 | IdP-initiated SSO |
備忘録を兼ねて、検証ステップを本記事にまとめます。
本記事は、検証ステップ編です。
構成のポイントと検証完了時の動作については、前編として別記事にまとめています！
「ちょうど AWS IAM Identity Center の SAML連携例を探していた」といった方や、AWS に限らず「とりあえず SAML 連携の構成例・構築例を知識として蓄えたい」といった方のご参考になれば嬉しいです！
目次
本記事は以下の構成です：
| # | 章題 | 概要 |
|---|---|---|
| 1 | 実装イメージ | システム構成を図示します |
| 2 | 検証ステップ | 検証時の構築作業や動作確認を実施した順に振り返ります |
| 3 | さいごに | 徒然と感想など... |
| 4 | 参考 | 検証にあたって参考にさせていただいた神記事たち |
長めの記事になってしまったので、適宜飛ばし読みしていただければと思います🚀
PC で開いていただけると Qiita 標準機能の目次が常に表示されますので、ご活用ください！
1. 実装イメージ
下図 (↓) は、検証時の構成を簡易にまとめてみたものです。
ユーザーアカウントについては手動プロビジョニング (既定) で、Entra ID 上のみならず AWS 上にもそれぞれ手動で作成しています。
アカウント名は AWS 公開情報の例を真似して「Nikki Wolf (NikkiWolf@domain.com)」にしました。
(参考：Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center)
構成のポイントについては、ぜひ前編をご参照ください！
2. 検証ステップ
構築と動作確認を合わせて、試行錯誤・勉強しながら 3つの画面を行ったり来たりし、以下の順で検証しました。
| # | 操作対象 | 作業概要 | 内容 |
|---|---|---|---|
| 2-1. | AWS | IAM Identity Center 有効化 | SAML連携構成の前提である "AWS IAM Identity Center-enabled account" を用意します |
| 2-2. | Entra ID | エンタープライズアプリ作成 | Entra がサービスプロバイダー (SP) との認証連携に利用する内部アプリ (エンタープライズアプリ) を作成します |
| 2-3. | AWS IAM & Entra ID | Identity Source 設定 & シングルサインオン設定 | AWS IAM と Entra ID 間でメタデータをやりとりし、SAML連携を構成します |
| 2-4. | Entra ID | テストユーザー作成 | Entra ID上にテストユーザーアカウントを作成します |
| 2-5. | My Apps | サインイン動作確認 (1) | この段階で動作確認：MyApps上にAWS IAMは表示されず、追加もできない、アクセスできない状態 |
| 2-6. | Entra ID | ユーザーとグループ設定 | エンタープライズアプリにて、SAML連携SSO利用対象者を設定します |
| 2-7. | My Apps | サインイン動作確認 (2) | この段階で動作確認：MyApps上にAWS IAMが表示され、サインインできるがAWSリダイレクト後にエラー発生 |
| 2-8. | AWS IAM | テストユーザー作成 | AWS IAM上にテストユーザーアカウントを作成します (※手動プロビジョニングのため発生するステップ) |
| 2-9. | My Apps | サインイン動作確認 (3) | この段階で動作確認：AWSへのサインインまで成功も、権限が無いので何も表示されない・操作できない状態 |
| 2-10. | Entra ID | ログ確認 (1) | サインインが成功した段階で、ログを確認します |
| 2-11. | Entra ID | 条件付きアクセスポリシー設定 | 条件付きアクセスポリシーを設定し、アプリサインイン時のアクセス制御を実装します |
| 2-12. | AWS IAM | Permission 設定 | AWS IAM上で管理者権限を設定し、テストユーザーアカウントに付与します |
| 2-13. | My Apps | サインイン動作確認 (4) | この段階で動作確認：AWSサインイン成功後、権限に応じた操作が可能に |
| 2-14. | Entra ID | ログ確認 (2) | サインインログから、条件付きアクセスポリシー評価結果を確認します |
Microsoft Intune 設定について
Intune によるデバイス管理まわりの構成は既存の流用で検証しました。本記事でも記載を割愛します🙏
サインイン動作確認について
今回は、各設定にどのような意味があるのかを確認したかったので、こまめに動作確認をはさんで検証しました。
(検証した順に本記事にも掲載します。)
「サインイン動作確認 (1)~(3)」と「ログ確認 (1)」を飛ばしても話はつながります！
本記事の姉妹記事にて、今回確認した動作を総じてフローにまとめていますので、お急ぎの方はこちらをご参考ください：Entra ID 資格情報で AWS にシングルサインオン！(①動作例)
以降、各ステップで実施したことを順にまとめます。
2-1. [AWS] IAM Identity Center 有効化
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | AWS | IAM Identity Center 有効化 | SAML連携構成の前提である "AWS IAM Identity Center-enabled account" を用意します |
- 参考：
今回の検証のために AWS 環境を新規取得したので、まるっきりまっさらな AWS 環境を SAML 検証に必要最小限な状態まで整えるところからスタートしました。
AWS 公開情報によると、前提として "AWS IAM Identity Center-enabled account" を用意する必要があるそうです。
Prerequisites
Before you can get started with this tutorial, you'll first need to set up the following:
- A Microsoft Entra ID tenant. For more information, see Quickstart: Set up a tenant in Microsoft documentation.
- An AWS IAM Identity Center-enabled account. For more information, see Enable IAM Identity Center in the AWS IAM Identity Center User Guide.
―― Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center - Prerequisites より (2025年7月9日閲覧)
早速 Enable IAM Identity Center ユーザーガイドを参照して用意していきます。
2-1. 作業ステップ (折りたたみました。左端の ▶ をクリックして展開)
写真上でアカウントIDが表示されている部分をグレーのボックスでマスクしました
-
ユーザーガイドに従って
https://console.aws.amazon.com/singlesignonを開くと「Enable IAM Identity Center」が表示されるので「Enable」ボタンをクリック
-
「Enable IAM Identity Center ~」画面に推移するので、リージョンなどを確認して右下の「Enable」ボタンをクリック
-
IAM Identity Center ダッシュボード画面に推移し、「You have successfully created ~」メッセージが表示されると完了です
You have successfully created the organization instance of IAM Identity Center {account ID}.
今回は試用版環境取得時に初期付与される管理者アカウントのようなもの (?) でサインインした状態で作業を行ったためか、結果 Organization インスタンスが作成されました。
参考 - Organization instance とは：Organization instances of IAM Identity Center
2-2. [Entra] エンタープライズアプリ作成
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | エンタープライズアプリ作成 | Entra がサービスプロバイダー (SP) との認証連携に利用する内部アプリ (エンタープライズアプリ) を作成します |
- 参考：
前提が整ったところで、次は連携用のアプリを作成していきます。
AWS IAM Identity Center との連携には、ラッキーなことにギャラリーアプリがあるということで活用しました。
参考 - ギャラリーとは：Microsoft Entra アプリケーション ギャラリーの概要
2-2. 作業ステップ (左端の ▶ をクリックして展開)
-
Entra 管理センター (
entra.microsoft.com) より ID > アプリケーション > エンタープライズ アプリケーション1 を開き、「すべてのアプリケーション」画面にて「新しいアプリケーション」をクリック
-
「Microsoft Entra ギャラリーを参照する」画面に推移するので、検索バーに「AWS IAM Identity Center」と入力し「AWS IAM Identity Center (successor to AWS Single Sign-On)」を選択
-
アプリの情報が表示されるので、正しいギャラリーアプリが選択されていることを確認して「作成」ボタンをクリック
「作成」ボタンを押す前に...
この段階で、アプリのフレンドリネームを設定することができます。
既定ではギャラリーアプリの名前がそのまま「名前」欄に入力されますが、編集が可能です。
なお、ここでつけた名前は後々エンドユーザーにも表示されるアプリ名になります。(管理者目線でもユーザー目線でもわかりやすい名前にするのがベスト)なお、今回検証では既定のアプリ名をそのまま使いましたが、特に「successor to AWS Single Sign-On」の部分が長いので編集すればよかったです！！
-
アプリ詳細画面に推移し、「アプリケーション {アプリ名} が正常に追加 ~」通知が表示されると完了です
アプリケーションの追加 アプリケーション {アプリ名} が正常に追加されました
以上で、エンタープライズアプリの "ガワ" を作成できました。
まだ接続先情報等々が入っていない空っぽの状態のため、これだけだと何もしないオブジェクトが Entra に増えただけの状態です。
← エンタープライズアプリの中身の設定は、次のステップ 2-3. Identity Source 設定 & シングルサインオン設定 で対応します。
2-3. Identity Source 設定 & シングルサインオン設定
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | AWS IAM & Entra ID | Identity Source 設定 & シングルサインオン設定 | AWS IAM と Entra ID 間でメタデータをやりとりし、SAML連携を構成します |
- 参考：
AWS IAM と Entra ID 間の接続を構成します。
このステップでは、AWS IAM Identity Center と Entra 管理センター 双方を開いてメタデータのやり取りが必要です。
AWS IAM Identity Center 側は、Entra からのメタデータをインポートしない限り Identity Source 設定画面を保存・閉じることができないので、一息に作業する必要がありました。
大まかな作業の流れは以下です：
| # | 操作対象 | 作業 | 画面 | 内容 |
|---|---|---|---|---|
| 1 | AWS IAM | Change identity source 設定 | Settings > Identity source | 「Change identity source」設定画面を開く |
| 2 | AWS IAM | External identity provider 設定 | Change identity source > Step 1 Choose identity souce | 「External identity provider」設定画面を開く |
| 3 | AWS IAM | Service provider metadata ファイル ダウンロード | Change identity source > Step 2 Configure external identity provider | 「Service provider metadata」ファイルをダウンロードする ※設定画面を閉じずにそのまま待機！ |
| 4 | Entra ID | SAML 設定 | エンタープライズアプリ > AWS IAM アプリ > シングルサインオン | 「SAML」設定画面を開く |
| 5 | Entra ID | Service provider metadata ファイル アップロード | SAML > 基本的なSAML構成 | 「Service provider metadata」ファイルをアップロードし、自動入力設定を保存する |
| 6 | Entra ID | フェデレーションメタデータ XML ファイル ダウンロード | SAML > SAML証明書 | 「フェデレーションメタデータXML」ファイルをダウンロードする |
| 7 | AWS IAM | フェデレーションメタデータ XML ファイル アップロード | Change identity source > Step 2 Configure external identity provider | IdP SAML metadata として「フェデレーションメタデータXML」ファイルをアップロードし、設定を保存する ※先ほど開いたまま待機していた画面で設定を保存して、作業完了 |
2-3. 作業ステップ (左端の ▶ をクリックして展開)
2-3-1. [AWS] Change identity source 設定
-
IAM Identity Center より Settings > Identity source タブを開き、「Actions」を展開して「Change identity source」をクリック
-
「Step 1 Choose identity source」画面に推移します
2-3-2. [AWS] External identity provider 設定
-
Change identity source 設定の「Step 1 Choose identity source」画面にて、「External identity provider」を選択し、「Next」ボタンをクリック
-
「Step 2 Configure external identity provider」画面に推移します
2-3-3. [AWS] Service provider metadata ファイル ダウンロード
- Change identity source 設定の「Step 2 Configure external identity provider」画面にて、「Service provider metadata」セクション右上の「Download metadata file」ボタンをクリック
- 「~_sp_saml_metadata.xml」ファイルを適切な場所に保存
(今回は作業用PCのローカル上に保存しました)
一旦この設定画面はこのまま開いたまま、次はしばらくEntra 管理センター上で作業します。
2-3-5. [Entra] Service provider metadata ファイル アップロード で再度この画面に戻ってきます！
AWS access portal sign-in URL について
「Step 2 Configure external identity provider」画面の「Service provider metadata」セクション中央部に表示されている「AWS access portal sign-in URL」は、SP-initiated SSO を利用する場合に Entra ID 管理センターに手入力します。
(今回の検証では順を追って動作確認したかったため、まだ SP-initiated SSO は構成していません。後日やりたいです。)
2-3-4. [Entra] SAML 設定
- Entra 管理センター より ID > アプリケーション > エンタープライズ アプリケーション > 先ほど 2-2. [Entra] エンタープライズアプリ作成 で作成したアプリを選択1
- アプリ画面のメニューより「シングルサインオン」を選択
- シングルサインオン方式選択画面が開くので「SAML」を選択
- 「SAML ベースのサインオン」画面に推移します
2-3-5. [Entra] Service provider metadata ファイル アップロード
- 「SAML ベースのサインオン」画面上部より「メタデータファイルをアップロードする」をクリック
- 「メタデータ ファイルをアップロードします。」メニューが開くので、フォルダアイコンをクリック > 先ほど 2-3-3. にて保存した Service provider metadata ファイルを選択して「追加」をクリック
-
「基本的な SAML 構成」メニューが開き、「{ファイル名} XML が正常にアップロードされました」通知が表示されます
SAML ファイルのアップロード {ファイル名} XML が正常にアップロードされました
-
Service provider metadata をアップロードすると、以下項目に値が自動的に入力されます
- 識別子 (エンティティ ID)
- 応答 URL (Assertion Consumer Service URL)
サインオン URL について
SP-initiated SSO を利用する場合に構成する項目です。
メタデータアップロードにより自動入力はされない項目でした。
利用する場合は、2-3-3. [AWS] Service provider metadata ファイル ダウンロード でメタデータファイルをダウンロードしたのと同じ IAM 設定画面の中央部より「AWS access portal sign-in URL」をコピーして貼り付けます。
(今回の検証では順を追って動作確認したかったため、まだ SP-initiated SSO は構成していません。後日やりたいです！)
-
「基本的な SAML 構成」画面にて値が入力されていることを確認してから、「保存」をクリック
-
「シングル サインオンの構成が正常に保存されました」通知が表示され、中央ペインにも値が反映されます
シングル サインオンの構成の保存 シングル サインオンの構成が正常に保存されました
-
構成保存完了後、すかさず「{アプリ} でシングル サインオンをtestしますか？」ポップアップが表示されるので、「いいえ、後でtestします」をクリック
属性とクレームについて
今回の検証では属性とクレームは既定値のままにしました。
AWS のガイドによると、Entra ID 上のゲストユーザー資格情報を使って AWS に SSO したい場合は、ゲストユーザーに限り NameID を user.email にするよう編集が必要とのことです。
-
参考：Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center - Step 3: Configure and test your SAML connection
(ページ末尾の "Microsoft Entra ID Guest Account Synchronization" に記載)
2-3-6. [Entra] フェデレーションメタデータ XML ファイル ダウンロード
- 「SAML ベースのサインオン」画面中央ペインをスクロールダウンし、「SAML 証明書」セクション下部のフェデレーション メタデータ XML「ダウンロード」をクリック
- 「{アプリ名}.xml」ファイルを適切な場所に保存 (今回は作業用PCのローカル上に保存しました)
2-3-7. [AWS] フェデレーションメタデータ XML ファイル アップロード
2-3-3. [AWS] Service provider metadata ファイル ダウンロード で開いたままにしていた設定画面に戻ります！
- Change identity source 設定の「Step 2 Configure external identity provider」画面にて、「Identity provider metadata」セクション右上の「Choose file」ボタンをクリック
- 先ほど [2-3-6.] にて保存した「{アプリ名}.xml」ファイルを選択し、画面下部の「Next」ボタンをクリック
- 「Step 3 Confirm change」画面に推移するので、各ステップの設定を確認してから「Review and confirm」セクション下部の入力欄に「ACCEPT」と入力し、「Change identity source」ボタンをクリック
-
「Configuring IAM Identity Center - Configuration in progress」進捗が表示されるので、おとなしく待ちます
プログレス表示下に「Do not leave this page」とあるので、うっかりページを閉じたりリフレッシュしたりしないようにしましょう。
検証時は数秒で終わりました。Configuring IAM Identity Center
configuring in progress
Do not leave this page while we are configuring IAM Identity Center.This process might take a few minutes.If you close this window before the process is complete, you might need to start again.
-
IAM Identity Center ダッシュボード画面に推移し、「You successfully changed ~」メッセージが表示されると完了です
(Identity source 設定欄の表示も更新されました)You successfully changed the identity source from IAM Identity Center to an external identity provider (IdP)
2-4. [Entra] テストユーザー作成
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | テストユーザー作成 | Entra ID上にテストユーザーアカウントを作成します |
次に、実際にアプリにシングルサインオンするユーザーを用意します。
Entra ID 検証環境に既存のユーザーアカウントを使ってもよかったのですが、AWS 公開情報の例で「Nikki Wolf」というユーザーが出てきたのでこれを再現してみました。
また今回、今後の検証環境運用のことを考えてグループ単位でもろもろ設定を実装したく、「AWS Users」というグループも用意しています。
(シンプルに、クラウド上に作成した静的セキュリティグループです)
新規ユーザーなので、忘れずにライセンスも付与します。
グループについて
SAML連携の構成において、エンタープライズアプリの割り当てに利用できます。
エンタープライズアプリに割り当てると、グループメンバーが SSO 利用可能になるほか、自動プロビジョニングを構成している場合はグループメンバーがプロビジョニング対象になります。
ただし現在仕様として、グループが階層構造になっている (ネストされている) 場合、子グループには設定が継承されません。
(子グループのメンバーはSSOできない、自動プロビジョニングもされない)
2-5. サインイン動作確認 (1)
このセクションを飛ばし読みしても話はつながります！🚀
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| テストユーザー | My Apps | サインイン動作確認 (1) | この段階で動作確認：MyApps上にAWS IAMは表示されず、追加もできない、アクセスできない状態 |
のちの比較用に、この段階でユーザー (Nikki Wolf) 目線の動作を確認してみました。
(AWS 公開情報にも、試しに見てごらん！とのインストラクションが。)
サインイン動作(1) (左端の ▶ をクリックして展開)
先ほど [2-4.] で用意した Nikki Wolf のアカウントで My Apps ポータル myapps.microsoft.com にサインインすると、以下写真の表示でした。
- Microsoft 系のアプリがずらっと並び、AWS は無い状態
- アプリの追加 > 新しいアプリの要求 一覧にも AWS は表示されない
- 当然 AWS IAM にはまだサインインできない
Nikki が My Apps ポータルからサインイン済みの Entra 資格情報を使って AWS IAM にシングルサインオンするには、Entra ID 側のエンタープライズアプリの対象ユーザーに含まれている必要があります。
← 2-6. [Entra] ユーザーとグループ設定 で対応します。
2-6. [Entra] ユーザーとグループ設定
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | ユーザーとグループ設定 | エンタープライズアプリにて、SAML連携SSO利用対象者を設定します |
- 参考：
テストユーザーアカウントが所属するグループを、エンタープライズアプリの対象に追加します。
2-6. 作業ステップ (左端の ▶ をクリックして展開)
- Entra 管理センター より ID > アプリケーション > エンタープライズ アプリケーション > 先ほど 2-2. [Entra] エンタープライズアプリ作成 で作成したアプリを選択1
- アプリ画面のメニューより「ユーザーとグループ」を選択
- 「ユーザーとグループ」画面上部より「Add user/group」をクリック
- 「割り当ての追加」画面が開くので、「ユーザーとグループ」下の「選択されていません」ハイパーリンクをクリック
- 「ユーザーとグループ」選択画面が開くので、対象を選択 (ユーザー または グループを選択)
ユーザーとグループの選択
ユーザーアカウント単位、またはグループ単位で選択が可能です。
今回検証ではグループを使いました。
なお、グループの利用には Entra ID P1 ライセンスが必要です。
- 「選択済み」メニューに自分が選択したユーザーまたはグループが表示されていることを確認してから「選択」ボタンをクリック
- 「割り当ての追加」画面にて、設定が入っていることを確認し、「割り当て」ボタンをクリック
- ユーザーとグループ：X個のグループ (またはユーザー) が選択されました
- ロールを選択してください：User
-
「ユーザーとグループ」画面に推移し、「アクセスが割り当てられました」通知が表示されると完了です
アプリケーションの割り当てが成功しました X ユーザーと X グループにアクセスが割り当てられました
2-7. サインイン動作確認 (2)
このセクションを飛ばし読みしても話はつながります！🚀
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| テストユーザー | My Apps | サインイン動作確認 (2) | この段階で動作確認：MyApps上にAWS IAMが表示され、サインインできるがAWSリダイレクト後にエラー発生 |
のちの比較用に、またこの段階でユーザー (Nikki Wolf) 目線の動作を確認してみました。
サインイン動作(2) (左端の ▶ をクリックして展開)
Nikki Wolf のアカウントで My Apps ポータル myapps.microsoft.com にサインインすると、今度は以下の動きになりました。
-
My Apps ポータル上に「AWS IAM Identity Center (successor to AWS Single Sign-On)」アプリが表示されている！
-
「AWS IAM Identity Center (successor to AWS Single Sign-On)」アプリをクリックすると、Microsoft のサインイン画面が表示されるので ID を選択 (サインイン済みのためパスワード入力は不要)
-
AWS 画面にリダイレクトされるも、エラー表示
問題が発生しました このコードは使用できません。もう一度試してください
エラーが出るのは想定の範囲内です...！
サインインを成功させるには Entra ID と AWS IAM 双方にユーザーアカウントが必要で、かつ今回は自動プロビジョニングを有効にしていない既定の手動プロビジョニング状態のため、AWS IAM 側に手動でユーザーアカウントを用意する必要があります。
← 2-8. [AWS] テストユーザー作成 で対応します。
2-8. [AWS] テストユーザー作成
手動プロビジョニングモード (既定) のため発生するステップです
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | AWS IAM | テストユーザー作成 | AWS IAM上にテストユーザーアカウントを作成します |
- 参考：
AWS IAM 側にテスト用ユーザーアカウントを用意します。
ユーザーが Entra の資格情報を使って AWS IAM にシングルサインオンできるよう、Entra ID の UPN と同じ値で AWS 側でも一意にユーザーを識別できるように作成します。
←このため、今回は Entra ID 側に Nikki Wolf (NikkiWolf@domain.com) を用意しているので、AWS IAM 側にも Nikki Wolf (NikkiWolf@domain.com) を用意します。
2-8. 作業ステップ (左端の ▶ をクリックして展開)
-
IAM Identity Center より Users を開き、「Add user」ボタンをクリック
-
「Step 1 Specify user details」画面が開くので、以下の値を入力し「Next」ボタンをクリック
- Username: NikkiWolf@domain.com
- Email address: NikkiWolf@domain.com
- First name: Nikki
- Last name: Wolf
- Display name: Nikki Wolf
User name と Email address 欄に、Entra ID 側に用意したアカウントの UPN/mailアドレスと同じ値を入力します
Entra ID 側に用意したアカウントで UPN とメールアドレスの値が異なる場合は、AWS ユーザー作成時に UPN に対応する値を Username に入れます
- UPN: 123456789@domain.com → AWS ユーザーの "Username" として設定
- メールアドレス: NikkiWolf@domain.com → AWS ユーザーの "Email address" として設定
-
「Step 2 Add user to groups - optional」画面が開くので、特になにもせず「Next」ボタンをクリック
-
「Step 3 Review and add user」画面が開くので、設定内容を確認し、「Add user」ボタンをクリック
-
IAM Identity Center ダッシュボード画面に推移し、「The user {username} was successfully added」メッセージが表示されると完了です
The user {username} was successfully added.
The user can now connect to the AWS access portal, and you can grant them permissions to accounts or applications so that they can access their assigned AWS accounts and cloud applications when they sign in to the AWS access portal.
2-9. サインイン動作確認 (3)
このセクションを飛ばし読みしても話はつながります！🚀
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| テストユーザー | My Apps | サインイン動作確認 (3) | この段階で動作確認：AWSへのサインインまで成功も、権限が無いので何も表示されない・操作できない状態 |
のちの比較用に、さらにこの段階でユーザー (Nikki Wolf) 目線の動作を確認してみました。
サインイン動作(3) (左端の ▶ をクリックして展開)
Nikki Wolf のアカウントで My Apps ポータル myapps.microsoft.com にサインインすると、今度は以下の動きになりました。
-
My Apps ポータルにて、「AWS IAM Identity Center (successor to AWS Single Sign-On)」アプリを選択
-
Microsoft のサインイン画面が表示されるので ID を選択 (サインイン済みのためパスワード入力は不要)
-
AWS アクセスポータルに移動できた！
ただし... アプリケーション/アカウントへのアクセス権が無いため、何も操作できず
ということで、シングルサインオン成功後に実際に AWS 側で何かするには、AWS 側で権限設定が必要です。
← 2-12. [AWS] Permission 設定 で対応します。
2-10. [Entra] ログ確認 (1)
このセクションを飛ばし読みしても話はつながります！🚀
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | ログ確認 (1) | サインインが成功した段階で、ログを確認します |
ここで、一旦シングルサインオン成功までは見届けることができたので、Entra ID に標準で用意されているログを確認してみました。
- 2-10-1. サインインログ
- 2-10-2. 使用状況と分析情報
- 2-10-3. 監査ログ
- 2-10-4. プロビジョニングログ
ログ (長いので折りたたみました汗 左端の ▶ をクリックして展開)
2-10-1. サインインログ
Entra ID では、テナントへのサインイン (Entra ID が認証するすべてのサインイン) 情報が記録されます。
(参考：Microsoft Entra サインイン ログとは)
エンタープライズアプリの、今回作成したアプリのメニュー配下に、このアプリに対するサインインをフィルタリングしたビューが用意されていました。
写真のサインインログは、2-7. サインイン動作確認 (2) の分のログです。
今回の動作をみていると、AWS 側にアカウントが無い状態でも Entra ID から AWS に認証情報を正常に連携できた時点でサインインログ上は「成功」表記になるようです。
実際のサインインから早くても15分ほど (遅いときは 30分ほど) してからログが上がってきます。
直近で記録されていたログを見ると、以下のようにユーザーやアプリ、デバイス、条件付きアクセスの評価結果を確認することができました。
デバイス情報
Entra に参加済みかつ Intune により準拠していると判定された管理端末を接続元として使っています
認証の詳細
認証方法は「Previously satisfied」により、成功 (true) したという結果になっています。
今回 Edge ブラウザから My Apps および AWS アクセスポータルにサインインしていますが、ブラウザ自体にサインインしておりその認証情報が引き継がれてシングルサインオンできています。
ちなみに、引き継がれるのは一次認証だけでなく、多要素認証を要求する場合は二要素目の認証も引き継がれます。
参考に、以下写真は別のタイミングで多要素認証を実施した際のログです。
アプリサインイン時に都度 MFA を要求したい場合は、セッションを切るなど一工夫必要になりそうです。
条件付きアクセス
この時点の接続条件では条件付きアクセスポリシーがひとつも適用されないという侘しい結果に...
← 2-11. [Entra] 条件付きアクセスポリシー設定 にて構成を更新します
レポート専用条件付きアクセスポリシーの一覧画面の写真は割愛します
「認証イベント」や「追加の詳細」については今回これといった特徴はありませんでした
2-10-2. 使用状況と分析情報
「使用状況と分析情報」は、アプリに対するサインイン挙動ログとして以下のインサイト提供に役立つそうです。
(参考：Microsoft Entra ID の使用状況と分析情報レポートとは)
- 組織内で最もよく使われるアプリケーションはどれか
- サインインに最も失敗したアプリケーションはどれか
- 各アプリケーションの上位のサインイン エラーは何か
- アプリケーションの最後のサインイン日はいつか
こちらも、今回作成したアプリのメニュー配下にこのアプリに対するイベントをフィルタリングしたビューが用意されていました。
2-10-3. 監査ログ
Entra ID 上の管理運用作業のうち、変更をともなうものが監査ログとして記録されます。
(参考：Microsoft Entra 監査ログとは)
エンタープライズアプリの、今回作成したアプリのメニュー配下に、このアプリに対する変更作業をフィルタリングしたビューが用意されていました。
試しに、一番上に表示されている「Add app role assignment to group」アクティビティログを展開すると、操作を実施した管理ユーザー (写真ではマスクしています) と操作内容を確認できました。
2-10-4. プロビジョニングログ
今回は自動プロビジョニングを実施していないため、空っぽでした。
本来はプロビジョニング処理結果 (エラー含め) を記録してくれるそうです。
(参考：How to download and analyze the Microsoft Entra provisioning logs)
2-11. [Entra] 条件付きアクセスポリシー設定
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | 条件付きアクセスポリシー設定 | 条件付きアクセスポリシーを設定し、アプリサインイン時のアクセス制御を実装します |
SAML連携したアプリは、条件付きアクセスポリシーを使ってアクセス許可 or ブロックの制御を実装することができます。
せっかくなので、ポリシーをいくつか割り当てました。
(すでにテナントに存在し「すべてのユーザー」割り当てにしていたポリシーを含め)
今回は Microsoft 推奨の条件付きアクセスポリシーを中心に、以下ポリシーを割り当てました。
- 参考：
ポリシーの構成についてはすでに素敵公開情報があるため、横着して本記事での解説は割愛します。
(リンクをご参考ください！)
適用される条件付きアクセス (左端の ▶ をクリックして展開)
テストユーザー (Nikki Wolf) が、AWS IAM Identity Center (successor to AWS Single Sign-On) にアクセスする際、評価されるポリシー：
- Block legacy authentication
- Block unknown or unsupported device platform
- Require approved client apps or app protection policy
- Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users
テストユーザー (Nikki Wolf) が、Windows デバイスからブラウザーを使って AWS IAM Identity Center (successor to AWS Single Sign-On) にアクセスする際、適用されるポリシー：
2-12. [AWS] Permission 設定
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | AWS IAM | Permission 設定 | AWS IAM上で管理者権限を設定し、テストユーザーアカウントに付与します |
シングルサインオン成功後、実際に AWS 側で何か操作するには、AWS 側で権限設定が必要です。
嬉しいことに AWS 公開情報に検証用権限構成例が載っていたので、これを実装しました。
作業の流れは以下です：
(すべて AWS IAM Identity Center にて実施)
| # | 作業 | 内容 |
|---|---|---|
| 1 | Permission set 作成 | 検証用に権限を絞った permission set を作成します |
| 2 | アカウント割り当て設定 | アカウントにユーザーと権限を割り当てます |
2-12. 作業ステップ (左端の ▶ をクリックして展開)
2-12-1. Permission set 作成
-
IAM Identity Center より Permission sets を開き、「Create permission set」ボタンをクリック
-
「Step 1 Select permission set type」画面が開くので、「Custom permission set」を選択し「Next」ボタンをクリック
-
「Step 2 Specify policies and permission boundary」画面が開くので、「Inline policy (not set)」を選択
(Inline policy 編集画面が開きます)
-
Inline policy 編集画面にて、「Edit statement - Statement1」ペイン下 Add actions 一覧より「Account」を選択
-
Add actions - Account 配下の以下チェックボックスを選択 (選択が json statement に反映されます)
- ListRegions
- GetRegionOptStatus
- DisableRegion
- EnableRegion
-
Add a resource 横の「Add」ボタンをクリック
-
「Add resource」ポップアップが表示されるので、Resource type 欄にて「All Resources」を選択し、「Add resource」ボタンをクリック
-
Inline policy が設定できたこと (action と resource が定義されていること) を確認して、画面右下の「Next」ボタンをクリック
-
「Step 3 Specify permission set details」画面が開くので、Permission set name 欄に権限名 (今回は RegionalAdmin) を入力し、「Next」ボタンをクリック
-
「Step 4 Review and create」画面が開くので、Step 1 ~ 3 が設定されていることを確認して、画面右下の「Create」ボタンをクリック
-
IAM Identity Center ダッシュボード画面に推移し、「The permission set {permission set name} was successfully created.」メッセージが表示されると、ひとまず権限の作成が完了です
2-12-2. アカウント割り当て設定
-
IAM Identity Center より AWS accounts を開き、アカウントを選択して「Assign users or groups」ボタンをクリック
AWSの世界では「アカウント」＝リソースコンテナであることを知らずに、ネーミングしてしまっていました (sandbox とかにしたかった...)
- 参考：AWS アカウントとは
-
「Step 1 Select users and groups」画面が開くので、「Users」タブを選択 > [2-8.] で作成したテストユーザーアカウントを選択し、「Next」ボタンをクリック
-
「Step 2 Select permission sets」画面が開くので、先ほど [2-12-1.] にて作成した permission set を選択し、「Next」ボタンをクリック
-
「Step 3 Review and submit」画面が開くので、Step 1 と 2 が設定されていることを確認してから「Submit」ボタンをクリック
-
「Configuring your AWS account - Configuration in progress」進捗が表示されるので、おとなしく待ちます
「do not leave this page」とあるので、うっかりページを閉じたりリフレッシュしたりしないようにしましょう。
検証時は数秒で終わりました。Configuring your AWS account... do not leave this page
Configuration in progress
Do not leave this page while we are configuring your AWS accounts. This process may take a few minutes based on the accounts and permission sets being configured. If you close this windows before the process is complete, you may need to start it again.
-
IAM Identity Center ダッシュボード画面に推移し、「We reprovisioned your AWS account successfully and applied the updated permission set to the account.」メッセージが表示されると完了です
以上で設定が完了しました🎉
2-13. サインイン動作確認 (4)
本セクションの動作含め、今回検証で確認した動作はすべて前編にまとめて掲載しています。
(すでに前編を読んでいただいた方には、本セクションの内容は繰り返しになります...!)
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| テストユーザー | My Apps | サインイン動作確認 (4) | この段階で動作確認：AWSサインイン成功後、権限に応じた操作が可能に |
設定が完了した段階で、ユーザー (Nikki Wolf) 目線の動作を確認します。
サインイン動作(4) (左端の ▶ をクリックして展開)
Nikki Wolf のアカウントで My Apps ポータル myapps.microsoft.com にサインインすると、以下のように意図した通りの動作を確認することができました🎉
-
My Apps ポータルにて、「AWS IAM Identity Center (successor to AWS Single Sign-On)」アプリを選択
-
Microsoft のサインイン画面が表示されるので ID を選択 (サインイン済みのためパスワード入力は不要)
-
AWS アクセスポータルに移動できた！ かつ、割り当てたアカウントが表示されているので、まずアカウントをクリックし、表示される permission set を次に選択！
-
コンソールが表示された！ (権限レベルに応じた情報が表示されます)
以後、付与した権限に応じた操作ができることを、おまけとして確認しました。
-
ナビゲーションバー上で設定 (歯車アイコン) を展開し、「リージョンを管理」をクリック
-
アカウントの設定画面が表示されるので、リージョン一覧からランダムに選択肢、「有効化」ボタンをクリック
-
「{選択したリージョン} リージョンを有効化」ポップアップ画面が表示されるので、「リージョンを有効化」ボタンをクリック
-
「{選択したリージョン} リージョンを有効にしました。」メッセージを確認
{選択したリージョン} リージョンを有効にしました。リージョンの現在のステータスは、[アカウント] ページで確認できます。AWS がリージョンの準備を完了すると、上部のナビゲーションバーにあるリージョンセレクターからアクセスできます。
-
しばらくすると、ナビゲーションバーから先ほど有効化したリージョンを選択できるようになりました
なお、今回は条件付きアクセスポリシーの許可条件を満たすパターンでアクセスしたので AWS アクセスポータルにリダイレクトされましたが、許可条件を満たさない (今回だと未登録端末かつMFAしない) とブロックされます。
さすがに長いので本記事では割愛しますが、その後アクセスブロックパターンも動作確認できました。
2-14. [Entra] ログ確認 (2)
| アクター | 操作対象 | 作業 | 内容 |
|---|---|---|---|
| 管理者 | Entra ID | ログ確認 (2) | サインインログから、条件付きアクセスポリシー評価結果を確認します |
意図したサインイン動作を確認できたところで、最後にサインインログを確認しました。
繰り返しになりますが、今回テストユーザーグループと「AWS IAM」アプリを対象に割り当てた条件付きアクセスポリシーは以下 4つです：
- Block legacy authentication
- Block unknown or unsupported device platform
- Require approved client apps or app protection policy
- Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users
2-14-1. サインインログ
2-13. サインイン動作確認 (4) で AWS にサインインした際のログを以下に掲載します。
サインインログ (左端の ▶ をクリックして展開)
基本情報
テストユーザー (Nikki Wolf) が AWS IAM Identity Center アプリに単一認証でのサインインに成功しています
デバイス情報
サインイン動作確認 (1)~(3) 実施時と同じく、Entra に参加済みかつ Intune により準拠していると判定された管理端末を接続元として使っています
認証の詳細
認証方法は「Previously satisfied」により、成功 (true) したという結果になっています。
今回 Edge ブラウザから My Apps および AWS アクセスポータルにサインインしていますが、ブラウザ自体にサインインしておりその認証情報が引き継がれてシングルサインオンできています。
条件付きアクセス
今回の接続条件 (コンプライアンス準拠した Windows 端末からブラウザを使ってアクセス) では、以下の評価結果となりました：
- Block legacy authentication：適用されない (ブラウザ=先進認証アプリのため、ブロックしない)
- Block unknown or unsupported device platform：適用されない (Windows = supported platform のため、ブロックしない)
- Require approved client apps or app protection policy：適用されない (iOS/iPadOS, Android に適用されるポリシー (Windows は適用対象外))
- Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users：適用される、許可条件 (compliant device) を満たすため、成功 = アクセス許可する
Block legacy authentication：
適用されない (ブラウザ=先進認証アプリのため、適用対象外。ブロックしない。)
Block unknown or unsupported device platform：
適用されない (Windows = supported platform のため、適用対象外。ブロックしない。)
Require approved client apps or app protection policy：
適用されない (iOS/iPadOS, Android に適用されるポリシーのため、Windows は適用対象外。)
Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users：
プラットフォームやクライアント条件なく一律適用される。
許可条件 (compliant device) を満たすため、成功 = アクセス許可する。
以上から、2-13. サインイン動作確認 (4) では以下白矢印のアクセス制御フローとなったことが分かります。
-
2-13. サインイン動作確認 (4) 時に適用されたアクセス制御 (白矢印)
-
[ご参考]アクセス制御全体像
(前編 Entra ID 資格情報で AWS にシングルサインオン！(①動作例) より再掲)
3. さいごに
以上のステップで、Entra ID と AWS IAM Identity Center を SAML 連携し、シングルサインオン (SSO) 成功を見届けることができました。
SAML認証連携は、どのアプリと連携するとしても Entra ID として具備されている設定項目は変わらず、どこをどの値で構成しどのタイプの証明書を連携するか etc はサービスプロバイダーとなるアプリ側要件で決まります。
AWS IAM Identity Center は AWS 公式のガイド記載が充実しており、必要な情報を取捨選択しながら検証を進めることができました。
試用版を無料で取得することもできますし、これから SAML 連携を勉強しはじめるところ、という方にも練習台としておすすめなアプリだなと思いました。
なお今回、ユーザープロビジョニングは既定の手動モード状態で、SSO 認証方式も IdP-initiated SSO での実装でした。
AWS IAM Identity Center としては自動プロビジョニングや SP-initiated SSO にも対応しているそうなので、また後日設定を追加してあらためて動作を確認してみたいです。
(参考：Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center)
また、自動プロビジョニングを使うシナリオでは AWS 側の権限設定もユーザー属性に応じて動的に構成するようなこともできるそうです (attribute-based access control, ABAC)。
こうした構成拡張性がある点も、ひとつで何度でもおいしいアプリですね。
(長い記事になったのに、網羅できていないという驚き)
想像以上に長くなってしまいましたが、最後まで読んでいただきありがとうございました！
4. 参考
感謝をこめて今回検証にあたって参考にさせていただいた記事を掲載いたします。
(SAML 連携全般に関する参考記事も含みます。)
Entra ID 資格情報で AWS にシングルサインオン！(①動作例) に掲載させていただいたのと同じ記事です。