【Amazon WorkSpaces】Azure ADを利用したSAML認証を試してみた

こんにちは。AWS CLIが好きな福島です。

はじめに

今回は2022/11/18にGAされたWorkSpacesのSAML認証をAzure ADを使い試してみたため、ブログに記載いたします。

Announcing General Availability for Amazon WorkSpaces Integration with SAML 2.0

参考

基本は以下のドキュメントを参考に設定しました。

Setting up SAML 2.0 - Amazon WorkSpaces

Azure AD側の設定は以下のドキュメントにあるリンク先を参考に進めました。

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html

※上記ドキュメントには、Azure AD以外のIdPの設定も記載されたリンクが載っているため、参考になるかと存じます。

考慮点

ドキュメントに記載されておりますが、この辺りがSAML認証をする場合の考慮点になるかと存じます。

• IdPは、ディープリンクまたはリレーステート URLを使用して、IdP起点の認証連携をサポートしていること
  (例えば、ADFS、Azure AD、Duo Single Sign-On、Okta、OneLogin、PingFederate、および PingOne for Enterpriseなど)
• WorkSpacesのディレクトリとして、AD コネクタまたはAWS マネージド Microsoft ADを利用していること(Simple ADは非推奨)
• Active Directory ユーザーと IdP ユーザーのsAMAccountNameおよび電子メール属性が一致していること
• Windows クライアントを利用している場合、バージョン 5.1.0.3029 以降であること
• macOS クライアントを利用している場合、バージョン 5.x 以降であること

概要図

SAML認証の流れは以下のイメージかと思います。

※今回は検証目的でAzure ADとEC2は同期していなく、idpとAD Connectorで別々のディレクトリを利用し、それぞれに同一ユーザーを作成しています。

作業の流れ

①エンタープライズアプリケーションの作成[Azure AD]
②アプリのフェデレーションメタデータ XMLをダウンロード[Azure AD]
③AWS IAM で SAML ID プロバイダーを作成する[AWS]
④SAML 2.0 フェデレーション IAM ロールを作成する[AWS]
⑤IAM ロールへのインライン ポリシー設定[AWS]
⑥SAML 認証応答のアサーションを設定する[Azure AD]
⑦フェデレーションのリレー状態を構成する[Azure AD]
⑧アプリケーションへのユーザー割り当て[Azure AD]
⑨アプリのリンクをコピー[Azure AD]
⑨WorkSpaces ディレクトリで SAML 2.0 との統合を有効にする[AWS]
⑩動作確認

①エンタープライズアプリケーションの作成[Azure AD]

• エンタープライズアプリケーションを押下

• 新しいアプリケーションを押下

• 独自のアプリケーションの作成を押下

• アプリの名前を任意で設定し、作成を押下

※複数のディレクトリへSAML認証する予定の場合、アプリ名にディレクトリ名など識別できる値を入れると良いと思います。

②アプリのフェデレーションメタデータ XMLをダウンロード[Azure AD]

• シングルサインオンの設定を押下

• SAMLを押下

• 以下のメタデータをダウンロード

https://signin.aws.amazon.com/static/saml-metadata.xml

• ダウンロードしたメタデータをアップロード

• 保存を押下

• フェデレーションメタデータ XMLをダウンロード

③AWS IAM で SAML ID プロバイダーを作成する[AWS]

• 名前とフェデレーションメタデータ XMLを設定し、IDプロバイダーを作成

④SAML 2.0 フェデレーション IAM ロールを作成する[AWS]

• 以下の情報を入力し、次へを押下

IDプロバイダー: ③で作成したプロバイダー
属性: SAML:sub_type
値: persistent

• 権限は後から付与するため、一旦スキップし、名前を設定しIAMロールを作成する

• 再度IAMロールの信頼関係を開き、Actionに"sts:TagSession"を追加する

⑤IAM ロールへのインライン ポリシー設定[AWS]

• インラインポリシーを作成を押下

• 以下のポリシーを設定する
  

【REGION】、【AWSアカウントID】、【ディレクトリID】は適切な値を指定する。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:【REGION】:【AWSアカウントID】:directory/【ディレクトリID】",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

• 名前を設定し、ポリシーを作成する。

• 以下の通り設定できればOK

⑥SAML 認証応答のアサーションを設定する[Azure AD]

• Azure AD側に戻り、属性とクレームを編集を押下

• クレームの変更

クレーム名	値
一意のユーザー識別子 (名前 ID)	user.mailnickname [nameid-format:persistent]
https://aws.amazon.com/SAML/Attributes/Role	ロールのARN,プロバイダーのARN
https://aws.amazon.com/SAML/Attributes/RoleSessionName	user.mailnickname
https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email	user.mail

⑦フェデレーションのリレー状態を構成する[Azure AD]

• 基本的なSAML構成の編集を押下

• リレー状態の設定を行う

リレーの状態に設定するURLは、リージョンごとに異なりますが、東京リージョンの場合は、以下のURLになります。

https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=【WorkSpacesの登録コード】

東京リージョン以外の場合は、以下のドキュメントを確認してください。

Setting up SAML 2.0 - Amazon WorkSpaces

⑧アプリケーションへのユーザー割り当て[Azure AD]

• ユーザーまたはグループの追加を押下

• 適切なユーザーを選択し、割り当てる

⑨アプリのリンクをコピー[Azure AD]

• https://myapps.microsoft.com/にアクセスし、アプリのリンクをコピー

◆コピーしたリンク例

https://account.activedirectory.windowsazure.com/applications/signin/xxxxx?tenantId=xxxxx

上記リンクのsignin以降をコピーし、https://myapps.microsoft.com/signin/ に付与する。

◆イメージ(このリンクを⑨で利用するため控えておく。)

https://myapps.microsoft.com/signin/xxxxx?tenantId=xxxxx

⑨WorkSpaces ディレクトリで SAML 2.0 との統合を有効にする[AWS]

• WorkSpacesの画面から認証を編集を押下

• SAML2.0 ID プロバイダーの編集を押下

• ユーザーアクセスURLに⑧でコピーしたリンクを張り付け、保存を押下

上記の画像の通り、設定前にテストを実施することも可能です。
ただし、本来はユーザー名がIdPから受け取った情報で固定されるのですが、テストの場合はユーザー名を自由に設定できたため、IdPから正しいユーザー名が連携されるかは別途確認が必要そうです。

⑩動作確認

• WorkSpacesクライアントの起動し、登録コードを入力

• サインインを続行を押下

• ブラウザが開き、Azure ADの認証を行うと以下の画面が表示されるので、Login to WorkSpacesが押下する

• WorkSpaces クライアントの画面が変わるため、PWを入力しログイン

※ユーザー名はSAMLで連携される名前が自動で入るようです。
そのため、考慮点に記載した通り、Active Directory ユーザーと IdP ユーザーのsAMAccountNameが一致している必要があるようです。

• WorkSpacesにログインできました！

終わりに

今回は、Azure ADを利用したSAML認証でWorkSpacesにログインしてみました。SAMLの知識が全然なかったため、Azure AD側のクレーム設定にすごくハマってしまいました...

また、IAMでIDプロバイダーの設定もしたことがなかったため、最初はよく分からず苦しみましたが、無事に検証ができてよかったです。

どなたかのお役に立てれば幸いです。

福島 和弥 (記事一覧)

2019/10 入社

AWS CLIが好きです。