AWS IAM Identity Center を利用して Azure AD のユーザー情報で AWS アカウントへのアクセスを試してみる

AWS IAM Identity Center を利用して Azure AD のユーザー情報で AWS アカウントへのアクセスを試してみる

Azure AD と AWS IAM Identity Center を連携させて、Azure AD の認証情報で AWS アカウントにアクセスする設定方法をまとめました。
Clock Icon2023.03.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Azure AD ユーザーの認証情報を使って AWS IAM Identity Center 経由で AWS アカウントにアクセスする方法を紹介します。以前にも同様のブログを書きましたが、AWS Single Sign-On 時代だったため、改めて書き直しました。手順に変わりがないか確認したい意図もありましたが、ほぼ同じ手順で設定できました。

構成と全体の流れ

構成図と設定内容を示します。

ユーザー/グループ情報の同期は SCIM による自動同期を採用しています。

設定の流れ

  1. SAML の信頼関係の構築
    • AWS IAM Identity Center でアイデンティティソースの設定変更
    • Azure AD でエンタープライズアプリケーションの作成
    • Azure AD と AWS IAM Identity Center 間で SAML メタデータの交換と設定
  2. ユーザー/グループ情報の同期設定
    • AWS IAM Identity Center で自動プロビジョニングの有効化
    • Azure AD と AWS IAM Identity Center 間の自動同期の設定
    • Azure AD で同期するユーザー/グループの選択
  3. AWS アカウントへのアクセス権の設定
    • アクセス許可セットの作成
    • AWS アカウントとユーザー/グループ、アクセス権限セットの紐付け

構成図中の AWS IAM Identity Center と AWS アカウント間の SAML の信頼関係の構築は「3. AWS アカウントへのアクセス権の設定」において AWS IAM Identity Center が自動的に設定するため括弧書きとしています。


設定

AWS IAM Identity Center を有効化し、アイデンティティソースが Identity Center ディレクトリ(AWS IAM Identity Center でユーザーを管理)の状態から設定を開始します。

SAML の信頼関係の構築

AWS IAM Identity Center から設定していきます。

アイデンティティソースを Azure AD に変更するために「設定」から「アイデンティティソースの変更」を選択します。

「外部 ID プロバイダー」を指定します。「Active Derectory」ではありません。

メタデータをダウンロードします。本メタデータを後ほど、Azure AD にアップロードします。

ここから、Azure AD の手順に移ります。

始めに Azure AD の「エンタープライズアプリケーション」を選択します。

AWS IAM Identity Center との連携用に「新しいアプリケーション」を選択します。

ギャラリーを「AWS」などで検索すると「AWS IAM Identity Center (successor to AWS Single Sign-On)」が検索結果に出てくるので選択します。

任意の名前をつけて「作成」します。今回は「AWS IAM Identity Center」としました。

名前は My Apps ポータルで表示されるアプリの名前として利用されます(後から変更できます)。

次に、「シングル サインオン」を選択して、SAML の信頼関係の設定を実施していきます。

方式の選択では「SAML」を選択します。

「メタデータ ファイルをアップロードする」を選択して、先ほど AWS IAM Identity Center からダウンロードしたメタデータファイルをアップロードして「追加」します。

メタデータファイルをアップロードすると識別子が表示されるため「保存」を選択します。

設定後にシングルサインオンをテストするかどうか問われますが、まだ AWS IAM Identity Center 側にユーザー情報を同期していないため後で実施します。そのため、「いいえ、後で test します」を選択します。

メタデータファイルのアップロード後は識別と応答 URL が登録されていることが分かります。

「属性とクレーム」の設定がありますが、本ブログでは既定の設定とします。AWS 側で ABAC (Attribute-Based Access Control) を行う際に属性情報を定義することがあります。

次に「SAML 署名証明書」から AWS IAM Identity Center にアップロードするフェデレーション メタデータ XML をダウンロードします。

AWS IAM Identity Center の画面に戻ります。アイデンティティソースの変更画面で Azure AD からダウンロードしたメタデータファイルをアップロードして次に進みます。

確認事項が表示されるため問題なければ「承諾」を入力して「アイデンティティソースを変更」します。

設定後はアイデンティティソースが「外部 ID プロバイダー」になっていることが確認できます。

以上で、SAML の信頼関係の構築は完了です。


ユーザー/グループ情報の同期設定

次に、Azure AD のユーザー/グループ情報を AWS IAM Identity Center 側に同期させます。

「設定」より自動プロビジョニングを有効にします。

有効にすると、SCIM エンドポイントとアクセストークン情報が表示されるため控えます。後で Azure AD 側で入力する必要があります。なお、アクセストーンは「トークンを表示」をクリックすることで表示されます。

Azure AD 側の設定に移ります。

エンタープライズアプリケーションのメニューから「プロビジョニング」を選択します。

「作業を開始」を選択して設定していきます。

プロビジョニングモードを「自動」にして、管理者資格情報に先ほど AWS 側で確認したエンドポイント情報をとアクセストークン情報を入力します。入力後に「テスト接続」を選択することで AWS 側との接続を確認できます。

テストは問題ないことが確認できます。

一度「保存」します。

続いて、属性情報のマッピングを設定します。マッピング設定では、Azure AD ユーザの属性情報を AWS IAM Identity Center ユーザーのどの属性情報にどのようにマッピングするかを定義します

プロビジョニングのマッピングメニューから「Provision Azure Active Directory Users」を選択します。

マッピング設定は、エンタープライズアプリケーションの作成時点で定義済みであるため、一から作成する必要はありません。ですが、AWS IAM Identity Center 側で必須の属性である「ユーザー名」「表示名」「姓」「名」にマッピングされる Azure AD の属性のうち、「姓」「名」は任意の設定項目となっていることから、「姓」「名」が設定されていない場合に同期エラーが発生します。その対策として、Azure AD のユーザ情報に「姓(surname)」「名(givenName)」が入力されていない場合のデフォルト値を設定しておきます。

givenName の設定です。「null の場合の既定値 (オプション)」において、値が入力されていないときの AWS 側の既定値を指定できます。今回はnullで設定してみます。

surname も同様に設定します。

さいごに忘れずに「保存」します。

以上で自動同期の事前設定ができたため、同期するユーザーまたはグループを選択します。エンタープライズアプリケーションの「ユーザーとグループ」を選択します。

「ユーザーまたはグループの追加」から AWS 側に同期するユーザーを選択します。

今回は事前に作成済みの次のグループを選択します。

  • グループ test-group-admin
    • ユーザー Test Admin

グループ選択後に「割り当て」して同期対象に追加完了です。

設定後に一覧に追加されていることを確認できます。

ユーザーの同期を開始するために「プロビジョニング」メニューから「プロビジョニングの開始」を実施します。

しばらく待つと初期サイクルが完了して、指定したグループ数と所属しているユーザーが同期されたカウントを確認できます。

AWS IAM Identity Center 側でもユーザーとグループが同期されていることを確認できます。

Azure AD ではプロビジョニングのログを確認できます。

また、監査ログとして、設定内容の更新履歴なども確認できます。

プロビジョニングのエラー通知設定もできます。入力後に「保存」を忘れないようにします。

以上で、ユーザーとグループ情報の同期設定は終了です。

少し話が逸れますが、シングルサインオンの残りの設定も見てみます。推奨事項としてブラウザ拡張機能の My Apps Secure Sign-in の導入があります。

また、拡張機能を入れると Step 5 において AWS IAM Identity Center にアップロードする用のフェデレーション XML をダウンロードすることもできました。

シングルサインオンのテストもできます。

テストを試してみます。作業をしているユーザーとは別のユーザーでテストしたかったため「他のユーザーとしてサインインする」を試してみます。

先ほど、AWS 側に同期したユーザー Test Adminでテストしたところ、正常動作を確認できました。SAML Request と SAML Response をダウンロードして確認できるのが良いですね。


AWS アカウントへのアクセス権の設定

AWS IAM Identity Center において、Azure AD から同期したユーザーに対して AWS アカウントにアクセスする権限を付与します。権限設定のイメージを把握するには次のブログが役立ちます。AWS SSO 時代のブログですが、考え方はあまり変わっていません。また、「アクセス権限セット」は現在「アクセス許可セット」と呼ばれます。

今回は権限として AWS 管理ポリシーである「AdministratorAccess」と「ReadOnlyAccess」権限を持つアクセス許可セットを作成し、グループに割り当てます。

「許可セット」メニューから「許可セットを作成」を選択します。

「カスタム許可セット」を選択します。

AWS マネージドポリシーとして「AdministratorAccess」を選択します。他にもポリシーを選択できます。インラインポリシーは AWS IAM Identity Center でポリシーを記載することでアクセス先のアカウントにポリシーを適用できますが、カスタマーマネージドポリシーと許可の境界(Permissions boundary)はアクセス先のアカウントにおいて事前に IAM ポリシーを作成しておき、AWS IAM Identity Center では、その IAM ポリシー名を指定することで設定します。

許可セット名、説明、セッション時間、リレー状態を設定します。

許可セット名に入力した名前は、AWS アクセスポータルで権限を選択する画面で表示されます。

リレー状態は AWS アカウントにアクセスした際に表示されるページを指定できます。今回は東京リージョンのホーム画面を設定しています。

リレー状態の入力内容です。

https://ap-northeast-1.console.aws.amazon.com/console/home

最後に、確認画面で確認して作成します。


同様に「ReadOnlyAccess」も作成します。


次に、作成したアクセス許可セットをユーザーと AWS アカウントに紐付けます。

メニューから「AWS アカウント」を選択して、権限を付与したいアカウントを選択して「ユーザーまたはグループを割り当て」をクリックします。複数のアカウントを選択できますが、今回は 1 つのみ選択しています。

次に、権限を付与するグループを選択します。Azure AD から同期したグループを選択しています。

付与したい許可セットを選択します。先ほど作成した「AdministratorAccess」と「ReadOnlyAccess」を選択しています。

最後に設定内容を確認して「送信」すれば、アクセス先の AWS アカウントに IAM ID プロバイダーと IAM ロールが作成され、アクセスできるようになります。

設定後に改めてアカウントを確認すると Permission sets に設定したアクセス許可セットが表示されていることが分かります。

以上でアクセス権の設定は終了です。


AWS アカウントへのアクセス

AWS アカウントへのアクセスは Azure AD の My Apps Portal からアクセスする方法と AWS IAM Identity Center の AWS アクセスポータルからアクセスする方法があります。


Azure AD の My Apps Portal からアクセス

My Apps Portal にサインインすると作成したエンタープライズアプリケーションが表示されているため、そこから AWS IAM Identity Center にまずはアクセスします。

https://myapps.microsoft.com/

AWS IAM Identity Center ではアクセスするアカウントと権限(アクセス許可セット)に対して、マネジメントコンソールでアクセスするか AWS CLI でアクセスするための一時的な認証情報を取得するか選択します。

試しに「ReadOnlyAccess」でマネジメントコンソールへのアクセスを試したところ、問題なくアクセスできました。


AWS アクセスポータルからアクセス

Azure AD の My Apps Portal からではなく、直接 AWS IAM Identity Center の AWS アクセスポータルからアクセスすることもできます。

AWS アクセスポータルの URL は環境毎に異なり、AWS IAM Identity Center の設定画面から確認できます。また、ID ストア IDの部分にグローバルで一意な文字列を指定することもできます(ただし、変更できません)。

https://<ID ストア ID>.awsapps.com/start

アクセスすると Microsoft アカウントの認証画面になります。

同期したユーザーで認証すると AWS アクセスポータルにアクセスできます。後は「Azure AD の My Apps Portal からアクセス」と同様です。

さいごに

AWS IAM Identity Center が AWS Single Sign-On だった頃に一度、同じ内容でブログを書きましたが、1 年以上経過していたため、改めて AWS IAM Identity Center と Azure AD の連携として書き直しました。AWS Single Sign-On だった頃とほとんど同じ手順でできました。

このブログがどなたかのご参考になれば幸いです。

参考情報

チュートリアル: Azure AD SSO と AWS IAM Identity Center (AWS Single Sign-On の後継) の統合 - Microsoft Entra | Microsoft Learn

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.