非Organizations環境のAWSアカウントにAzure ADのユーザーからSSOしてみた

はじめに

こんにちは。大阪オフィスの林です。

非Organizations環境のAWSアカウントに対して、Azure ADユーザーからのSSOを検証する機会がありましたので、手順をまとめておきたいと思います。Organizations環境であれば、AWS SSOなどの選択肢も出てくるかと思いますが、今回の検証は非Organizations環境のためAWS SSOは採用できません。本記事が、非Organizations環境でAzure ADユーザーを使ったAWSマネージメントコンソールへのSSOをご検討されている方の参考になれば幸いです。

構成の概要

今回検証する構成の概要は下記のとおりです。

• Azure側
• Azure ADに紐づけて作成する「エンタープライズアプリケーション」で、AWSマネージメントコンソールにSSOするためのアプリケーションを作成します。
• 作成したSSO用のエンタープライズアプリケーションに、SSOさせるAzure ADのユーザーを割り当てます。
• AWS側
• Azure側で作成したSSO用のエンタープライズアプリケーションをIDプロバイダーとして登録します。
• 作成したIDプロバイダーに、SSO後の認可のためのIAMロールを作成し紐付けます。
• エンタープライズアプリケーションのデプロイ時にAWSとの連携が必要になるため、プロビジョニング用のIAMユーザーを作成します。

ざっくりですが構成はこんな感じです。

やってみた

Azure側の作業①

Azure ADは既に存在する前提で進めます。Azure ADの設定内、左メニューから「エンタープライズアプリケーション」を選択します。

「新しいアプリケーション」を選択します。

「AWS Single-Account Access」というアプリケーションがあるので、検索し選択します。

任意の名前を入力後、「作成」を選択します。

「アプリケーションの追加」の処理が開始します。

数秒で「アプリケーションの追加」が完了します。

左メニューから「シングルサインオン」を選択します。

「SAML」を選択します。

初回はポップアップが表示されるので「はい」を選択します。

デフォルトでも動作しますが、「ユーザー属性とクレーム」でセッションのタイムアウトなどオプション的な設定をすることも出来ます。

「SAML署名証明書」から「フェデレーションメタデータXML」をダウンロードします。

AWS側の作業

AWSマネージメントコンソールにログインしIAMのダッシュボードから、左メニューの「IDプロバイダ」-「プロバイダを追加」を選択します。

「SAML」を選択し、任意の「プロバイダ名」を入力後、「メタデータドキュメント」でAzure側作業の最後にダウンロードしたXMLファイルを選択し「プロバイダを追加」を選択します。

プロバイダが作成されました。

次にIAMロールを作成します。ここで作成するIAMロールはSSO後のAWSマネージメントコンソールでの認可に使用されるIAMロールとなります。左メニューの「ロール」-「ロールの作成」を選択します。

「SAML2.0 フェデレーション」を選択し、SAMLプロバイダーに、AWS側作業の冒頭で作成したIDプロバイダを選択後「プログラムによるアクセスとAWSマネージメントコンソールによるアクセスを許可する」を選択し、次のステップに進みます。

割り当てるロールの権限は要件に合わせて設定してください。繰り返しになりますが、ここで作成するIAMロールはSSO後のAWSマネージメントコンソールでの認可に使用されるIAMロールとなります。本手順では「AdministratorAccess」のロールを割り当てて、次のステップに進みます。

必要に応じてタグを設定し次のステップに進みます。

任意のロール名を入力後、「ロールの作成」を選択します。

IAMロールが作成されました。

次にAzure側のエンタープライズアプリケーションプロビジョニング用のIAMユーザーに割り当てるIAMポリシーを作成します。左メニューの「ポリシー」-「ポリシーの作成」を選択します。※IAMユーザーはIAMポリシー作成後に作成します。

プロビジョニング用のIAMユーザーはIAMロールの参照だけが出来ればいいので、「JSON」タブから下記のJOSNをコピペして次のステップに進みます。

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

必要に応じてタグを設定し次のステップに進みます。

任意のポリシー名を入力後、「ポリシーの作成」を選択します。

IAMポリシーが作成されました。

次にAzure側のエンタープライズアプリケーションプロビジョニング用のIAMユーザーを作成します。左メニューの「ユーザー」-「ユーザーを追加」を選択します。

任意の「ユーザー名」を入力し、アクセスの種類で「プログラムによるアクセス」を選択します。※AWSマネージメントコンソール操作用のユーザーを作成するわけではないのでAWSマネージメントコンソール操作の権限は不要です。

「既存のポリシーを直接アタッチ」を選択し、先ほど作成したIAMポリシーを選択後、次のステップに進みます。

必要に応じてタグを設定し次のステップに進みます。

内容を確認し「ユーザーの作成」を選択します。

「アクセスキーID」と「シークレットアクセスキー」は、次の工程のAzure側のプロビジョニングで必要になるので、csvでダウンロードしておくか、表示されている内容をメモしておきます。

IAMユーザーが作成されました。

Azure側の作業②

再度Azureに戻りエンタープライズアプリケーションのプロビジョニングを行っていきます。左メニューの「プロビジョニング」を選択し「作業の開始」を選択します。

プロビジョニングモードを「自動」とし、「clientsecret」に先ほどメモした「アクセスキーID」を入力し、「シークレットトークン」に先ほどメモした「シークレットアクセスキー」を入力します。

入力後「テスト接続」を行い、正常に接続できることを確認しておきます。

設定した内容を保存します。

数秒で保存の処理は終わります。

「×」でプロビジョニングの編集画面を閉じます。

「プロビジョニングの開始」を選択します。

プロビジョニングが開始されます。

「プロビジョニングの編集」を選択します。

「プロビジョニングの状態」を「オン」にし「保存」を選択します。

完了するまで数秒待ちます。

最後に、プロビジョニングが完了したエンタープライズアプリケーションにAzure ADのユーザーを割り当てます。左メニューの「ユーザーとグループ」から「ユーザーまたはグループの追加」を選択します。

「ユーザー」を選択します。「選択されていません」という文字がリンクになっているのでクリックします。

SSOさせるAzure ADのユーザーを選択します。

「ロール」を選択します。「選択されていません」という文字がリンクになっているのでクリックし、AWS側の作業で作成したロールを選択します。

ユーザーおよびロールが選択できたら「割り当て」を選択します。

エンタープライズアプリケーションにAzure ADのユーザーが割り当てられました。

動作確認

ここまでで設定作業は完了したので、動作確認をしてみます。 https://myapps.microsoft.com/にアクセスします。作成したエンタープライズアプリケーションが表示されるので「AWS Single-Account Access」を選択します。

ユーザーを選択して、Azure ADの認証を行います。（手元の環境だと複数のAzure ADユーザーが居たのでアカウントの選択画面が表示された（？）のかもしれません。1ユーザーのみであればそのまま認証画面に遷移するのかもしれませんが、その部分の確認はできませんでした。）

Azure ADの認証後、自動でAWSマネージメントコンソールに遷移しました。フェデレーションログインという内容で、作成したIAMロールにAzure ADのユーザーが紐付いていることが確認できました。

まとめ

手順自体は少々長くなってしまいましたが、非Organizations環境のAWSアカウントに対して、Azure ADユーザーからのSSOを試すことができました。Azure側、AWS側双方でどの部分の機能を使えば良いかがある程度分かったので非常に勉強になりました。この記事が非Organizations環境でAzure ADユーザーを使ったAWSマネージメントコンソールへのSSOをご検討されている方の参考になれば幸いです！

以上、大阪オフィスの林がお送りしました！