Amazon WorkSpaces で Microsoft Entra ID の SAML 認証を試してみた

こんにちは。
今更ながら Amazon WorkSpaces で SAML 連携を実施する機会があり、いろいろ触ってみましたので、
今回は Microsoft Entra ID を利用した SAML 連携設定を紹介したいと思います。

構成イメージ
設定手順
動作確認
さいごに

構成イメージ

今回設定するSAML認証のイメージ図です。
Entra IDをIAM IDプロバイダーとして登録し、WorkSpacesディレクトリの多要素認証方法として指定することで、多要素認証でEntra ID認証を利用することができるようになります。
図の中では省略していますが、AD認証にはEC2で構築した検証用ADサーバを利用するため、AD Connectorを作成して連携先ADに検証用ADサーバを指定しています。また、WorkSpacesはPersonal(個人)を利用します。
本記事では、検証用AD/AD Connector/WorkSpacesの基本的な設定が実施された環境に対して、Entra IDを用いた多要素認証設定を追加設定する手順を説明します。

設定手順

今回設定する手順は以下の通りです。
AWSとAzureのコンソールを行き来するので、分かりやすいように()内に操作するコンソールを書いています。

①エンタープライズアプリケーション作成 (Azure)
②SAML基本設定/フェデレーションメタデータXMLダウンロード(Azure)
③SAML ID プロバイダー作成 (AWS)
④IAMロール作成/インラインポリシー設定(AWS)
⑤SAML認証応答のアサーション設定 (Azure)
⑥フェデレーションのリレー状態構成 (Azure)
⑦アプリケーションへのユーザー割り当て/リンクコピー(Azure)
⑧WorkSpacesディレクトリでSAML2.0統合を有効化 (AWS)

以上の設定を順を追って説明していきます。

①エンタープライズアプリケーション作成 (Azure)

まずはEntra IDにSAML認証用のエンタープライズアプリケーションを追加していきます。
Azure管理コンソールでEntra IDの画面を開き、エンタープライズアプリケーションを新規作成します。

アプリケーションの新規作成画面で「独自アプリケーションの追加」を選択し、任意のアプリ名を入力します。
「アプリケーションでどのような操作を行いたいですか？」の箇所については、一番下の「ギャラリー以外」を選択して
アプリケーションを作成します。

②SAML基本設定/フェデレーションメタデータXMLダウンロード(Azure)

エンタープライズアプリケーションの作成が完了したら、作成したアプリケーションの「シングルサインオン」画面を開きます。
デフォルトで「無効」となっているシングルサインオン方式を「SAML」に設定します。

続いて、以下のURLからAWS提供のメタデータXMLをダウンロードします。
https://signin.aws.amazon.com/static/saml-metadata.xml

ダウンロードしたメタデータXMLをアップロードして、「保存」を押下します。

SAML設定画面に戻ったら、「SAML証明書」欄のダウンロードリンクから、メタデータXMLファイルをダウンロードします。
ここでダウンロードしたXMLファイルを用いて、AWS側のIDプロバイダー設定を実施します。

③SAML ID プロバイダー作成 (AWS)

続いてはAWS側の設定となります。
AWSマネジメントコンソールを開いて、IAM＞IDプロバイダを開きます。
「プロバイダを追加」を押下して以下の通り設定します。
・プロバイダのタイプ：SAML
・プロバイダ名：任意
・メタデータドキュメント：手順②でダウンロードしたメタデータXMLファイルを選択
設定出来たらIDプロバイダを作成します。

④IAMロール作成/インラインポリシー設定(AWS)

続いて、SAML認証で利用するIAMロールを作成します。
IAM＞ロールを開き、「ロールを作成」を押下します。
作成画面が開いたら、以下の通り設定し、「次へ」を押下します。
・信頼されたエンティティタイプ：SAML2.0フェデレーション
・SAML2.0ベースのプロバイダー：手順③で作成したIDプロバイダ
・許可されるアクセス：プログラムによるアクセスのみを許可する
・属性：SAML:sub_type
・値：persistent

その他の設定はデフォルトのまま、任意のロール名で一度ロールを作成します。
ロールが作成出来たら、ロールの信頼関係設定で、信頼ポリシーのActionに”sts:TagSession”を追加し、保存します。

ロールの設定が完了したら、最後に以下の通りインラインポリシーを追加します。
ポリシー内の対象リージョン/アカウントID/ディレクトリIDは、それぞれご自身が利用する予定のものに置き換えてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:＜対象リージョン＞:＜対象AWSアカウントID＞:directory/＜WorkSpacesディレクトリID＞",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

⑤SAML認証応答のアサーション設定 (Azure)

さて、ここまできたらAzure管理コンソールに戻って、作成したアプリケーションへAWS側の情報を追加していきます。
手順①で作成したアプリケーションの「シングルサインオン」画面を開き、「属性とクレーム」を編集します。
編集画面が開いたら、属性を以下の通り編集します。
※デフォルトで設定されている属性/クレームは削除してください。

クレーム名	名前識別子の形式	値
一意のユーザー識別子 (名前 ID)	永続的	user.mailnickname [nameid-format:persistent]
https://aws.amazon.com/SAML/Attributes/Role	– (デフォルト)	④で作成したロールのARN,③で作成したプロバイダのARN (arn:~,arn:~のようにカンマ区切りで記載する)
https://aws.amazon.com/SAML/Attributes/RoleSessionName	– (デフォルト)	user.mailnickname
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email	– (デフォルト)	user.mail