先日、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 初心者なのですが、AWS 公式の手厚いサポート記事と巷の心強い有志ブログのおかげで、無事にSSO成功まで見届けることができました。
備忘録を兼ねて、構成と動作を本記事にまとめます。
長くなってしまったので、検証ステップは別記事としてまとめます！
目次
本記事は以下の構成です：
| # | 章題 | 概要 |
|---|---|---|
| 1 | 実装イメージ | システム構成とポイントをまとめます |
| 2 | 動作例 | ユーザー目線のサインインエクスペリエンスをまとめます |
| 3 | さいごに | 徒然と感想など... |
| 4 | 参考 | 検証にあたって参考にさせていただいた神記事たち |
1. 実装イメージ
下図 (↓) は、検証時の構成を簡易にまとめてみたものです。
AWS 公開情報の例を真似して、テストユーザーとして「Nikki Wolf (NikkiWolf@domain.com)」を用意しました。
続けて、構成のポイントを順にまとめます：
1-1. ユーザープロビジョニング
1-2. アクセス制御
1-3. 権限設定
1-1. ユーザー プロビジョニング
今回は、まず試しに手動プロビジョニングモード (既定のまま) にしています。
このため、Entra ID 上のみならず AWS 上にもそれぞれ手動でユーザーアカウントを作成しています。
AWS IAM では SCIM (System for Cross-domain Identity Management) がサポートされているため自動プロビジョニングも可能です。
(参考：SCIM profile and SAML 2.0 implementation)
自動プロビジョニングモードを使う場合は、AWS側でユーザーをメンテする必要なく、Entra ID 側のユーザーが連携され AWS 側に作成/変更反映される動作になるそうです。
(こちらの動きはまた後日あらためて検証したいです)
参考 - 自動プロビジョニングとは
- 自動プロビジョニングとは？を解説してくれる記事：
Microsoft Entra ID でのアプリ プロビジョニングとは - AWS IAM - Entra ID SAML連携時の自動プロビジョニング動作を開設してくれる記事：
Microsoft Entra ID と IAM Identity Center を連携させて、AWS アカウントへのログインを実現させる - AWS 公式の自動プロビジョニング実装時の検討事項：Considerations for using automatic provisioning
1-2. アクセス制御
また、SAML連携構成後は Entra ID 条件付きアクセスポリシーを使って AWS IAM へのアクセス制御が可能なため、こちらも実装しました。
今回 Entra ID、Intune は他の検証でも利用している既存の開発環境を利用しており、アクセス制御も環境に既存の Microsoft 推奨ポリシーをいくつか適用しました。
- 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
今回利用したポリシーの組み合わせだと、以下の制御が適用されます：
1-3. 権限設定
条件付きアクセスポリシーによる評価の結果アクセスが許可された場合 AWS にアクセス可能ですが、その後どのアカウント/アプリケーションに対してどのくらい操作可能かは AWS 側の permission 設定で構成します。
今回は AWS 公開情報のありがたいインストラクションに沿って、カスタムで「RegionalAdmin」permission set を用意しました。
{
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"account:ListRegions",
"account:GetRegionOptStatus",
"account:DisableRegion",
"account:EnableRegion"
],
"Resource": [
"*"
]
}
]
}
(参考：Step 2.1: Create a RegionalAdmin permission set in IAM Identity Center)
2. 動作例
今回確認できた動作をまとめると、以下図のフローになります。
続けて、動作のポイントを順にまとめます：
2-1. ポータルアクセス
2-2. Entra ID 条件付きアクセスによる制御
2-3. AWS permission sets による制御
2-1. ポータルアクセス
-
My Apps のアプリ一覧より、「AWS IAM Identity Center (successor to AWS Single Sign-On)」アプリをクリックします
-
Microsoft のサインイン画面が表示されるので ID を選択します (サインイン済みのためパスワード入力は不要)
2-2. Entra ID 条件付きアクセスによる制御
許可条件を満たす場合
-
AWS アクセスポータルにリダイレクトされます。
(ユーザーにpermission setが付与されている場合、権限選択画面が最初に表示されます)
-
[ご参考] サインインログでは、AWS IAM Identity Center サインイン時に適用されたポリシーの結果が「成功」と表示されます。
許可条件を満たさない場合
-
アクセスブロック画面が表示されます。
(ブロックメッセージは、許可/ブロック条件により異なります。写真は、多要素認証を満たさなかった場合の表示です。)
-
[ご参考] サインインログでは、AWS IAM Identity Center サインイン時に適用されたポリシーの結果が「失敗」と表示されます。
2-3. AWS permission sets による制御
権限が付与されている場合
-
AWS アクセスポータルリダイレクト後、権限選択画面が表示されます。
-
権限選択後、コンソールが表示され、権限レベルに応じた操作が可能です。
権限が付与されていない場合
- AWS アクセスポータルにはリダイレクトされますが、何も表示されず何も操作できません。
AWS アクセスポータルに移動しました
管理者からアプリケーションと AWS アカウントへのアクセス件が付与されたら、ここで確認できます。
本記事に記載した動作を実現するまでの検証ステップについては別記事としてまとめていますので、ご興味のある方はぜひこちらもよろしくお願いいたします！
3. さいごに
今回実装した範囲では手動プロビジョニングということで、管理者目線だと Entra ID と AWS 双方でアカウントを作成・管理しています。
ユーザー目線では、AWS のアカウントは全く意識せずサービスを利用できる点で、自動プロビジョニングが無い状態でもすでに利便性を感じました。
DX化で利用するシステムが増える中、IDやパスワードが増えたり何度も認証したりしないといけないのは手間になります。
今回、シングルサインオンで生産性が向上することを体感できました。
また、SAML連携したアプリへのサインイン時に条件付きアクセスポリシーを適用できるのも利点ですね。
当方 AWS 初心者のため、IAM Identity Center のセキュリティをどう固めるかについて無知だったのですが、慣れ親しんだ条件付きアクセスで簡単にデバイスをはじめ接続元条件に応じたアクセス制御分岐を実装することができました。
ただ、完全に AWS 側の知識ゼロでは連携構成できず、今回は AWS の公開情報と有志のブログ記事が大変参考になりました。
感謝をこめて今回検証にあたって参考にさせていただいた記事を掲載いたします。
(SAML 連携全般に関する参考記事も含みます)
4. 参考