IAM ID プロバイダを使用した Azure AD との SAML 認証連携とマネジメントコンソールログイン

エンタープライズクラウド部小林(嵩) です。

複数のクラウドサービス導入が進み、認証情報の管理工数削減やセキュリティガバナンスの強化等目的に、シングルサインオン（SSO）の仕組み導入は良くある話かと思います。

AWS マネジメントコンソールへのアクセスにつきましても、Azure AD と SAML 認証連携する為に下記2種類の方法が御座いますが、本記事では後者の IAM ID プロバイダにて Auzre AD を ID プロバイダとする方法を紹介します。

（雑に言うと）AWSマネジメントコンソールログインに毎回 IAM ユーザ払い出したり面倒だし、パスワードいっぱい管理するのツラいので、すでにある Azure AD との連携方法記載します。方法は2種類ありますが、そのうちの1つについて記載します。

Identity Center (旧SSO) を利用する方法
IAM ID プロバイダを利用する方法

前提
ユースケース
動作概要
作業内容
おわりに
参考資料

前提

ID認証基盤として既に Azure AD をご利用中であることを前提とします。

（雑に言うと）ログインする為の認証情報をどこに持たせるか、で、Azure AD を使用したユーザ管理を既に行っており、これを流用したい場合を前提とします

ユースケース

Organization マスタ―アカウント管理者権限をお持ちの場合、まずは AWS IAM Identity Center（旧：AWS Single Sign-On）ご利用をご検討いただくと、ID プロバイダの導入や運用がしやすくなります。

上記に該当しない場合、本記事記載の IAM ID プロバイダにて Azure AD と連携する形となります。

（雑に言うと）Organization 導入済みでこの管理権限があるイケてる方々は別です。その他の一般人は本記事の方法になります

動作概要

SAML 認証フローは一般に、サービスプロバイダ側が認証の起点となる SP-initiated と、ID プロバイダ側が認証の起点となる IdP-initiated の2種類があります。

IAM ID プロバイダを用いた Azure AD との SAML 認証連携の場合は後者の、IdP-initiated の動作となります。

大まかな動作は以下の図のとおりとなります。
後述する「動作確認」画面を見ていただくと、イメージがつきやすいかもしれません。

作業内容

概要を以下の図に示します。

1. エンタープライズアプリケーションの新規作成

Azure 側では、既存の SaaS アプリケーションをテナントに統合する為に、エンタープライズアプリケーションを新規作成します。

SAML 認証連携先のアカウント毎にエンタープライズアプリケーションを作成する形となり、ここで設定したエンタープライズアプリケーションの名前が、Azure AD のアプリ一覧にも反映される為、アカウントを一意に識別可能な名前（※1）を設定します。

「Azure Active Directory」>「エンタープライズアプリケーション」>「新しいアプリケーション」の順にクリック
Azure AD キャラリーの参照にて「AWS Single-Account Access」を検索し選択
名前欄に SAML 認証連携先のアカウントを一意に識別可能な名前（※1）を設定し「作成」をクリック

※1 アカウントエイリアスを設定する等

2. エンタープライズアプリケーションの設定

エンタープライズアプリケーションにて、シングルサインオンの設定を進めていきます。

識別子と応答URLは同じ設定値とし、デフォルトのままで問題ありません。
複数のエンタープライズアプリケーションが存在する場合、識別子のみ「#」記号を含む記載とします。

項目	設定例
識別子	https://signin.aws.amazon.com/saml#my-account
応答URL	https://signin.aws.amazon.com/saml

フェデレーションメタデータ XML を作業端末にダウンロードし、Azure 側の作業は一旦止め、AWS 側の設定を行っていきます。

作成したエンタープライズアプリケーション内で「シングルサインオン」>「SAML」の順にクリック
基本的なSAML構成にて「編集」をクリック
先述した「識別子」と「応答URL」を設定し、「保存」をクリック
SAML証明書にて「フェデレーションメタデータXML」をダウンロード

3. IAM ID プロバイダの新規作成

IAM コンソールにて、ID プロバイダの設定を進めていきます。
設定項目と設定値は以下のとおりとします。

項目	設定値
プロバイダのタイプ	SAML
プロバイダ名	（任意の値）
メタデータドキュメント	取得した「フェデレーションメタデータXML」をアップロード
タグ	（適宜追加）

IAM コンソールにて「IDプロバイダ」>「プロバイダを追加」の順にクリック
先述の設定を行い、「プロバイダを追加」をクリック
正常に登録された場合、画面キャプチャのとおりのポップアップが表示される

4. ログイン時の権限作成（IAMロール）

Azure で認証されたユーザがマネジメントコンソールログイン時に付与される権限（IAMロール）を作成します。

項目	設定値
信頼されたエンティティタイプ	SAML 2.0 フェデレーション
SAML 2.0 ベースのプロバイダー	（前項で作成した ID プロバイダーを指定）
プログラムと AWS マネジメントコンソールへのアクセスを許可する	有効
許可ポリシー	（任意の値）
ロール名	（任意の値）
説明	（任意の値）

一例となりますが、ログインユーザに応じて下記 3 種類のロールを用意し、用途に応じたポリシーを設定します。

用途	ポリシー例
管理者用ロール	AdministratorAccess
開発者用ロール	PowerUserAccess
閲覧用ロール	ReadOnlyAccess

IAM コンソールにて「ロール」>「ロールを作成」の順にクリック
「SAML 2.0 フェデレーション」「（前項で作成した ID プロバイダー）」「プログラムと AWS マネジメントコンソールへのアクセスを許可する」を指定し「次へ」をクリック
普段ログインユーザに付与しているものと同じ要領で任意のポリシーを選択
同じく、任意のロール名、説明を入力

5. ログイン時の権限取得用の IAM ユーザ・ポリシー作成

Azure から IAM ロール名を取得する為の IAM ユーザ・ポリシーを作成します。

今回作成するポリシーは他のユーザと共有することがない為、簡略化してインラインポリシーで作成します。別途 IAM ポリシー作成しグループに付与し、このグループに IAM ユーザを含めるなど、各環境のポリシーに沿った設定としてください。

IAMユーザ

項目	設定値	設定例
ユーザー名	（任意の値）	AzureADRoleManager
許可を設定	（下記インラインポリシーを参照）

インラインポリシー

項目	設定値	設定例
ポリシー名	（任意の値）	AzureAD_SSOUserRole_Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
            "iam:ListRoles"
            ],
            "Resource": "*"
        }
    ]
}

IAMユーザの作成

IAM コンソールにて「ユーザー」>「ユーザーの作成」の順にクリック
任意のユーザ名（例えば AzureADRoleManager ）を入力し「次へ」をクリック
今回は後程インラインポリシーを設定する為、グループやポリシーは設定せずに「次へ」をクリック
設定内容を確認し「ユーザの作成」をクリック

インラインポリシーの作成

作成した IAM ユーザ名をクリック
「許可」タブにて、「インラインポリシーを作成」をクリック
「JSON」をクリックし、先述のインラインポリシーを入力し「次へ」をクリック
任意のポリシー名（例えば AzureAD_SSOUserRole_Policy ）を入力し「ポリシーの作成」をクリック

アクセスキーの取得

作成した IAM ユーザの「セキュリティ認証情報」タブにて、「アクセスキーを作成」をクリック
AWSとしてはアクセスキーなどの長期的な認証情報を使用することは避けることがベストプラクティスとなる為、代替案が表示される
アクセスキーを登録する必要がある為、いずれかのユースケースを選択し、「上記のレコメンデーションを理解し、アクセスキーを作成します」にチェックして「次へ」をクリック
必要に応じて説明を入力し、「アクセスキーを作成」をクリック
アクセスキーが作成される為、必ず「.CSVファイルをダウンロード」をクリックしてから「完了」をクリックする

6. エンタープライズアプリケーションの設定

前項までで AWS 側の設定はすべて完了した為、Azure 側の残る設定を進めていきます。

これまでに作成したエンタープライズアプリケーションにて、AWS 側で作成した IAM ユーザのアクセスキーを登録し、IAM ロール名を取得できるようにします。

その後、エンタープライズアプリケーションにユーザを追加し、各ユーザがマネジメントコンソールにログインした時の権限を指定します。

プロビジョニング

項目	設定値
プロビジョニングモード	自動
clientsecret	（取得した Access key ID ）
シークレットトークン	（取得した Secret access key ）
プロビジョニング状態	オン

ユーザーとグループ

表示名	割り当てられたロール
（任意のユーザ）	（AWS側で準備した IAM ロール）

プロビジョニング

作成したエンタープライズアプリケーション内で「プロビジョニング」>「プロビジョニング」の順にクリック
下記設定を行う
プロビジョニングモード：自動
clientsecret：（取得した Access key ID ）
シークレットトークン：（取得した Secret access key ）
「テスト接続」をクリックし、画面上部に「指定した資格情報にはプロビジョニングを有効にする権限があります」と表示がされたことを確認後、「保存」をクリック
画面を更新し、同プロビジョニング画面にて「プロビジョニングの状態」を「オン」にして「保存」をクリック

ユーザーとグループ

「ユーザーとグループ」>「ユーザーまたはグループの追加」をクリック
Azure AD 上のユーザと、AWS 上に作成した IAM ロールの紐づけを行う

7. 動作確認

AWS 側、Azure 側の設定はすべて完了しました。

登録したユーザにてログインし直し、Azure AD のアプリ一覧に接続してみると、作成したエンタープライズアプリケーション名のアプリが表示されています。

https://myapps.microsoft.com/

作成したエンタープライズアプリケーションをクリックすることで、指定した IAM ロールで AWS マネジメントコンソールにログインが出来ます。

おわりに

以上が Azure AD と連携した AWS マネジメントコンソールへのログイン設定の流れとなります。
Identity Center (旧SSO) を利用する方法は弊社ブログでも多く取り上げられておりますが、そもそも Organization 導入すらまだ、、となった場合、まずは IAM ID プロバイダも試してみてください。

また Identity Center (旧SSO) を利用する方法について興味があれば、以下のブログもご参照ください。

blog.serverworks.co.jp

IAM ID プロバイダを使用した Azure AD との SAML 認証連携とマネジメントコンソールログイン

前提

ユースケース

動作概要