株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

トップ > Amazon Workspaces の SAML 認証 に Okta を連携してみた

Amazon Workspaces の SAML 認証 に Okta を連携してみた

皆様、こんにちは。

ネットワールドSE の目木です。

今回はAmazon WorkspacesにおいてOktaと連携してSAML認証を構成するための手順を紹介します。

 

 テスト環境

事前準備としてAmazon WorkspacesのディレクトリおよびWorkspaceは構成済みの状態から始めています。ネットワーク構成上、プライベートサブネットとパブリックサブネットは分割しており、Workspacesはプライベートサブネット、NAT Gatewayはパブリックサブネットに配置して、Workspacesからインターネットへはアクセス可能な環境としています。（SAMLの構成には関係ないです）

Workspaceの展開手順については過去記事でも紹介していますので、よければそちらをご確認ください。

blogs.networld.co.jp

 

 SAML構成の手順

大まかな手順は以下の通りです。

1. SAML IdPアプリケーションの作成（Okta）

2. SAML 用 ID Providerの作成（AWS IAM）

3. SAML 用 IAMポリシー および IAMロールの作成（AWS IAM）

4. SAML IdPアプリケーションの調整（Okta）

5. ディレクトリのリダイレクト先を調整（Amazon Workspaces）

手順1でSAML IdPのアプリケーションを作成後に、手順4で再調整を入れていますが、これは手順1で作成したアプリケーションの情報をもとに、手順2および手順3が進められる、かつ手順2および手順3で取得できる情報がSAML IdPのアプリケーション側でも必要になるためです。

なお、今回の設定手順については以下のAWSドキュメントを参考としています。

docs.aws.amazon.com

 

 SAML認証とは？

実際の構築に入る前に、今回扱うSAMLについて少しだけ説明をいれておきます。

SAML認証とは、一般的には異なるドメイン間でのシングルサインオン（SSO）を実現する方法の一つとして知られる認証手法です。

ユーザーにサービスを提供する側であるService Provider（SP）と認証システムを提供するIdentity Provider（IdP）にて構成され、IdPからSPへと認証結果をもとに情報が連携されることで動作します。

今回の場合はAmazon WorkspacesがSP、OktaがIdPにあたります。

実際に触ってみると、Amazon Workspacesに対するアクセス許可を付与する動作のため、完全にSSOまで実装できるわけではないのですが、そのあたりも含めて手順を見ていきたいと思います。

 

 手順1. SAML IdPアプリケーションの作成（Okta）

最初はOktaの管理コンソールからSAML IdPアプリケーションを作成します。

Oktaの管理コンソールにログイン後、左側メニューにて[アプリケーション] > [アプリケーション]と展開して[アプリ統合を作成]をクリックします。

アプリの種類として「SAML 2.0」を選択します。

一般設定としてアプリ名、アプリのロゴ、アプリの可視性について設定します。

  • アプリ名：任意（Amazon Workspaces）
  • アプリのロゴ：任意（今回はAmazon Workspacesのロゴを拝借）
  • アプリの可視性：表示（非表示としてSP-Initiatedに限定することも可能）

続けてSAMLの設定を行うのですが、AWS側での設定が必要となるものが多いため、適宜ダミーの設定を入れながら進んでいきます。

  • シングルサインオンURL：ダミーURL　※手順4で調整
  • オーディエンスURI：ダミーの値　※手順4で調整
  • デフォルトのRelayState：

    https://relay-state-region-endpoint/sso-idp?registrationCode=registration-code　
    ※<relay-state-region-endpoint> = "workspaces.euc-sso.ap-northeast-1.aws.amazon.com" （アジアパシフィック (東京) リージョンの場合）
    ※<registration-code> = Amazon Workspaces のディレクトリID

  • 名前のIDフォーマット：Unspecified（デフォルト）
  • アプリケーションのユーザー名：Oktaユーザー名　※値は環境次第
  • 次でアプリケーションのユーザー名を更新：作成・更新（デフォルト）

ここで設定した[アプリケーションのユーザー名]はAmazon Workspacesの認証におけるアカウント情報としても利用されます。Amazon Workspacesの認証ではドメインユーザーアカウントのsAMAccountNameが使用されますので、そことマッチするように設定値を選択してください。

（今回はOktaにローカルアカウントを作成してテストしますので、後ほどOktaユーザー名＝ドメインユーザーのsAMAccountNameとなるように調整してユーザーを作成します）

 

最後にアプリケーションのタイプとして「これは当社で作成した社内アプリです」を選択してアプリの作成を終了します。

アプリ作成後はアクティブなアプリケーションとして一覧にアイコンが表示されます。

作成したアプリケーションをクリックして認証タブへと移ります。

[SAML属性]の欄にて編集をクリックして、[プロファイル属性ステートメント]を追加します。

Amazon Workspacesとしては「PrincipalTag:Email」と「RoleSessionName」が必須項目となります。

ここで「PrincipalTag:Email」のEメール情報はOktaで認証したアカウントとAmazon Workspacesで認証するアカウントの間で合致している必要があります。

また、「RoleSessionName」はCloudTrailで認証ログを確認した際のアカウント名となりますので、個人が判別できる値とすることが推奨されます。今回はログイン時のアカウント名としました。

名前

フォーマット

値

https://aws.amazon.com/SAML/Attributes/
PrincipalTag:Email

指定なし

user.email

https://aws.amazon.com/SAML/Attributes/
RoleSessionName

指定なし

user.login

これでSAML IdPアプリケーションを一旦作成できましたので、最後にメタデータを入手してAWS側の作業に移ります。
同じく[認証]タブの[サインオン方法]欄にメタデータURLが記載されていますので、このURLにWebブラウザでアクセスしてxmlファイルをして保存しておきます。

 

 手順2. SAML 用 ID Providerの作成（AWS IAM）

AWSの管理コンソールに移りIAMサービスにおいてSAML用のIDプロバイダを作成します。

[IAM] > [アクセス管理] > [IDプロバイダ]と展開して[プロバイダを追加]を選択します。

以下の通り設定を進めます。

  • プロバイダのタイプ：SAML
  • プロバイダ名：任意の値
  • メタデータドキュメント：Oktaで取得したxmlファイルをアップロード

その他オプションとして[SAML暗号化]、[タグを追加]とありますが、今回は未設定のままIDプロバイダを作成します。

IDプロバイダ作成後、メタデータが取得できますので、メタデータを開いて[サインインURL]と[Entity ID]を取得します。

これらの情報に加えて、IDプロバイダのARN情報も必要になりますので、そちらもメモしておきます。

 

 手順3. SAML 用 IAMポリシー および IAMロールの作成（AWS IAM）

 

続けて、IAMのポリシーおよびロールを作成します。

[IAM] > [アクセス管理] > [ポリシー]と展開して[ポリシーの作成]を選択します。

ドキュメントにサンプルがあるので、それをコピーして作成します。

https://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/setting-up-saml.html#embed-inline-policy


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:<REGION-CODE>:<ACCOUNT-ID-WITHOUT-HYPHENS>:directory/<DIRECTORY-ID>",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}“
                }
            }
        }
    ]
}

<REGION-CODE> = "ap-northeast-1"（東日本リージョン（東京））

<ACCOUNT-ID-WITHOUT-HYPHENS> = 12桁のアカウントID

<DIRECTORY-ID> = Amazon Workspaces のディレクトリID

 

ポリシー名を入力して作成を完了します。

ここで作成したポリシーをロールへと割り当てていきます。

[IAM] > [アクセス管理] > [ロール]より[ロールの作成]を選択します。

エンティティ情報を以下のとおり設定します。

  • 信頼されたエンティティタイプ：SAML 2.0フェデレーション
  • SAML 2.0 ベースのプロバイダー：手順2で作成したID Provider
  • 許可されるアクセス：プログラムによるアクセスのみを許可する
  • 属性：SAML:sub_type
  • 値：persistent

許可ポリシーとして、先ほど作成したIAMポリシーを選択します。

名前を付けてロールの作成を完了します。

作成したロールの信頼ポリシーにアクションとして「TagSession」を追加します。

[<作成したロールを選択>] > [信頼関係タブ]と開いて[信頼されたエンティティ]欄の[信頼ポリシーを編集]をクリックします。

画面右側の[STSのアクションを追加]から「TagSession」にチェックをいれてポリシーを更新します。

作成が完了した後はID Providerと同様、ロールのARN情報をメモしておきます。

 

 手順4. SAML IdPアプリケーションの調整（Okta）

手順2で取得したメタデータ情報をOktaのSAML IdPアプリへ追加します。

対象のアプリを選択して、[一般]タブの[SAML設定]を編集します。

[②SAMLを構成]まで移動し、シングルサインオンURLにメタデータ内のサインインURL、オーディエンスURIにEntity IDを入力して、編集を終了します。

続けて、[認証]タブから[プロファイル属性ステートメント]を追加します。

名前

フォーマット

値

https://aws.amazon.com/SAML/Attributes/Role

URI参照

<ロールのarn>,<ID Providerのarn>

最後にOkta側のサインオンURLを確認します。

[認証]タブの画面から、[サインオン方法] > [SAML2.0]の[詳細]ページを開いて[サインオンURL]をメモしておきます。このURLをAmazon WorkspacesのSAML認証時のリダイレクト先として指定します。

 

 手順5. ディレクトリのリダイレクト先を調整（Amazon Workspaces）

Amazon Workspaces のディレクトリ設定においてSAML 2.0のIdP情報を入力します。

[Workspaces] > [ディレクトリ]と開き、対象のディレクトリを選択して、[認証]欄において[編集]をクリックします。

「SAML2.0アイデンティティプロバイダの編集]を選択し、以下の通り入力して設定を保存します。

  • SAML 2.0 認証の有効化：有効
  • ユーザーアクセス URL：手順4でメモしたOkta IdPアプリのサインオンURL
  • IdP ディープリンクパラメータ名：RelayState
    ※ここはIdPの製品に依存して変化するが、Oktaの場合は"RelayState"

以上で、設定は完了です。

 接続確認

テスト用のOktaユーザアカウントはADサーバから同期する、Oktaのローカルアカウントを作成するなど選択肢がいくつかありますが、今回は最も簡易であるローカルアカウントを作成してテストしました。

フェデレーションを成立させるための要件として、Workspaceに割り当てているアカウントとOktaユーザーアカウントの間でユーザー名、メールアドレス情報が一致している必要がありますので、その点だけ注意してOktaの管理コンソールからアカウントを作成します。

  • ユーザータイプ：ユーザー
  • 姓名：任意の値
  • ユーザー名：AD上のアカウントのsAMAccountNameと同値
  • メインのメールアドレス：AD上のアカウントのメールアドレスと同値

アカウント作成後、[ユーザー選択] > [アプリケーション]タブ > [アプリケーションを割り当て]と操作して、SAML IdPアプリケーションを割り当てます。

以上にて、テストユーザーによるWorkspacesへのSAML IdPアプリの利用が可能となりました。

手元の端末にてWorkspacesのクライアントアプリを起動して認証を行います。

初回接続時は登録コードの入力が必要になります。2回目以降は保存された登録コードをもとに自動接続が可能です。（1）

登録コード先にアクセスするとユーザー/パスワード入力画面ではなく、SAML IdPへのリダイレクト用のボタンが表示されます。（2）

リダイレクト後にWebブラウザ上でOktaのSAML IdPアプリによる認証を行います。Okta側で多要素認証を有効としている場合はこのタイミングで実行されます。（3,4）

認証完了後、AWSの画面へと遷移して、Workspacesクライアントアプリの起動を求められます。この裏でOktaからAWSのIAMへのフェデレーションが行われており、Amazon Workspacesへのアクセス権限を取得しています。（5）

起動したWorkspacesクライアントアプリにはフェデレーションによって受け渡されたユーザー名が入力された状態となっており、パスワードを入力することでWorkspaceが起動します。（6,7,8）

 

以上でSAML認証実装後もWorkspaceが問題なく起動することが確認できました。

なお、この結果からもわかる通り、本設定だけではAmazon Workspacesの認証までシングルサインオンで通すことはできません。

シングルサインオンの実装には別途証明書認証を構成する必要があるようなのですが、そこはまたの機会にご紹介できればと思います。

 

 まとめ

今回はAmazon Workspaces + OktaによるSAML認証の構成について紹介してきました。

Amazon Workspacesではアカウント管理の観点のみならず、多要素認証の実装という観点でもOktaやEntra IDのようなアイデンティティプロバイダを利用する利点がありますので、ぜひ実装をご検討ください。

最後まで読んで頂き、ありがとうございました。

 

ymeki-nw

お問い合わせはこちら

紹介した製品・サービスについて、ご検討の方はまずはお気軽にご相談ください。

お問い合わせ
  • はてなブックマーク
  • LINE
  • Pinterest