NSX Advanced Load Balancer Workspace ONE アプリケーションのモダナイゼーション セキュリティ ネットワーク

NSX ALB のVIPでSAML認証によるユーザ認証をやってみる。既存システムにもゼロトラストを!

VMware NSX Advanced Load Balancer (NSX ALB) では、仮想サービス (Virtual Service / VIP)を サービスプロバイダー(SP) として動作させ、外部IDプロバイダ(IdP)と連携したSAML認証をサポートしています。これによりユーザ認証情報ベースで様々なセキュリティレベルを設定することができます。例えば、既存のシステムに「SAML認証」 を導入することもできたりします。今回はVMware NSX Advanced Load Balancer と IdPである VMware Workspace ONE Access を用いた SAML認証の設定例を紹介いたします。

「SAML認証」とは

ユーザーのIDを検証するプロセスとして「認証」という技術があり、システムに接続したいユーザーを確認するために日々いろいろなところで使われています。
近年では、IDプロバイダー(IdP)と呼ばれる「ユーザー・アカウントを管理するサービス」が登場し、みなさまも企業でSaaSを利用する際に、IdPの仕組みを使った「シングルサインオン/SSO」を使って複数のSaaSに接続しているのではないでしょうか。
「認証プロセス」をIdPに委任することで、「一度ユーザ認証すれば、その認証情報で、複数のSaaSを使える!」という、簡単・便利・セキュア!な使い方ができてしまいます。

こうした「シングルサインオン」には、「SAML認証」という標準規格を利用することもあります。

 

「SAML認証」では、ユーザー・SP・IdPの三者間で認証情報を交換してあげて、任意のシステムと相互運用できるように設計され標準化された形式になっています。

  • クライアント :リソースにアクセスしようとしているユーザー
  • サービスプロバイダー(SP):クライアントのサービス接続を許可する前にIdPに、「認証プロセス」をIdPに委任するコンポーネント(接続したいシステム/アプリやログイン先となるSaaSサービスなど)
  • Identity Provider (IdP):シングルサインオンの認証サービスを提供するコンポーネント。単一の認証ポイントを提供

 

このように、IdPが単一の認証ポイントになりますので、クライアントがシステム/アプリにアクセスするために複数のクレデンシャルを覚えておく必要もなくなり、クライアントとしてもハッピーになる仕組みです。一度ログインすることで、1セットのクレデンシャルで複数のアプリにアクセスできます。ハードウェア、認証用ソフトウェア保守、システム/アプリの認証機構の追加オーバーヘッドも減らしていくこともできます。

 

「SAML認証」の動作イメージ

サービスプロバイダー(SP)が開始するSSOの場合、クライアントはまず SP に接続し、SPは認証のためにクライアントを IdP にリダイレクトします。 IdP での認証に成功すると、クライアントは SP にリダイレクトされます。これにより、システム/アプリ へのアクセスが可能になります。
NSX ALB では、このようなSPによって開始されるSSOをサポートしていまして、仮想サービス (Virtual Service / VIP)を サービスプロバイダー(SP) として動作させることができます。

 

NSX ALB 仮想サービスでの SAML認証の処理フロー

ここからは仮想サービス (Virtual Service / VIP)を SPとして動作させ、IdPの仕組みを使った「シングルサインオン」を使ってアプリに接続していくまでの処理フローを下図を用いて見ていきたいと思います。

 

 

  1. クライアントから、アプリへのアクセス。アプリとして、NSX ALB「仮想サービス (Virtual Service / VIP)」を サービスプロバイダー(SP) として動作

     

  2. クライアントが未認証の場合、「仮想サービス」 はSAMLリクエスト生成し、クライアントを IdP SSOサービスにリダイレクト (302リダイレクトを使用)

     

  3. クライアントのブラウザが、IdP SSOサービスにGETリクエストを送信(HTTP GETリクエストのURLクエリ文字列内でSAMLリクエストを送信)
    例:

     

  4. クライアントが同一ブラウザ内の過去セッションでIdP未認証の場合、クレデンシャル情報を入力する認証フォームをクライアントに提示し、クレデンシャル情報が検証されIdP認証を実施

     

  5. 認証成功後、IdP SSOサービスから以下の内容を含むSAML認証応答パラメータを返信
    – 信頼できる(改竄のない)IdPからである証明・クライアントがIdPで正常に認証されたことの証明・ユーザID、など

     

  6.  POSTリクエストを使用し、クライアントから「仮想サービス」にSAML認証応答パラメータを送信
    例:

     

  7. 「仮想サービス」は SAMLアサーションを検証し、クライアントのCookieを設定し、クライアントの1.でアクセスした「仮想サービス」のURIへリダイレクト ( 302リダイレクトを使用)

     

  8. 「仮想サービス」から送られたCookieを使用してアプリ(仮想サービス)にアクセスするため、クライアントがGET要求を送信

     

  9. クライアントのアプリへのアクセスに成功

     

     

NSX ALB 仮想サービス と Workspace ONE Access のSSO連携 設定例

NSX ALB 仮想サービス (Virtual Service / VIP)を SPとして動作させる中で、IdPとしては VMware Workspace ONE Access が選択いただけます。ここからは、こうした組み合わせを利用していく際の設定例や動作概要を見て行きたいと思います。
バージョン情報:
NSX ALB  : 21.1.3
VMware Workspace ONE Access : 21.08

 

① Workspace ONE Access へのアプリ登録

まずは、Workspace ONE Accessにアプリ登録をします。「ABC App」という企業アプリに対して、SSOできるようにします。
Workspace ONE Access ログイン > カタログ > 新規 > SaaSアプリケーションの編集 > 名前 > 「ABC App」と入力し、「次へ」をクリックします。
構成 > 認証タイプ で「SAML 2.0」を選択 > 構成で「手動」を選択 > 各項目に下記を入力します。
シングルサインオン URL  : 「https://abc.corp.local/sso/acs/」
受信先 URL : 「https://abc.corp.local/sso/acs/」
アプリケーションID : 「SAML_app_ABC」

 

# 「https://abc.corp.local/」がSSOを挿入したい 「仮想サービス」のURLと一致するようにします。「シングルサインオン URL」と「受信先 URL」に同様のURLを入力します。
# 「アプリケーションID」は、任意の文字列となり「仮想サービス」の設定にある「エンティティID」と一致するようにします。

 

ユーザ名の形式  : 「メールアドレス」を選択
ユーザ名の値  : ${user.email}
アクセスポリシー > 「default_access_policy_set」 を選択し、保存します。

 

 

② Workspace ONE Access のアプリへのユーザ割り当て

次は、上記ようにWorkspace ONE Accessに登録したアプリを選択し、アクセスを許可するユーザをアサイン(割り当て)します。

 

カタログ > 「ABC App」にチェクを入れる > 割り当て > アサインするユーザを検索し追加します。
図の例では 「snagatoishi」と「mmiki」 というユーザをアサインしています。

Workspace ONE Access での設定は以上となります。

 

③ NSX ALB コントローラへWorkspace ONE Access (IdP) を登録

続いて、この Workspace ONE Access 設定を用いて、NSX ALB「仮想サービス (Virtual Service / VIP)」に「SAML認証」の設定をしていきます。

Workspace ONE Access ログイン > カタログ > 設定 > SAML メタデータ > 「IDプロバイダ(IdP)メタデータ」をクリック

 

以下のようにブラウザに表示された「IDプロバイダ(IdP)メタデータ」のXML全体をコピーします。

 

NSX ALB コントローラにログイン > アプリケーション > テンプレート > セキュリティ > 認証プロファイル > 作成 > 各項目に下記を入力 or 選択し、保存します。
名前 :「SAML-Auth-Profile」と入力
タイプ:「SAML」を選択
IDPメタデータ:前述でコピーした「IDプロバイダ(IdP)メタデータ」のXML全体を貼り付け(入力)
エンティティタイプ:ユーザ提供のエンティティIDを使用

 

NSX ALB (Avi) コントローラにログイン > アプリケーション > テンプレート > セキュリティ > SSOポリシー > 作成 > 各項目に下記を入力 or 選択します。
名前 :「sso-policy」と入力
タイプ:「SAML」を選択
デフォルトの認証プロファイル:「SAML-Auth-Profile」を選択(先述で作成した「認証プロファイル」です)

 

 仮想サービスへの「SAML認証」の設定

「仮想サービス (Virtual Service / VIP)」に「SAML認証」の設定をしていきます。
NSX ALB コントローラにログイン > アプリケーション > 仮想サービス > ポリシー > アクセス > SAML > 各項目に下記を入力 or 選択し、保存します。
SSOポリシー :「sso-policy」を選択(先述で作成した「SSOポリシー」です)
エンティティID:「SAML_app_ABC」と入力(先述のVMware Workspace ONE Accessで設定した「アプリケーションID」と一致させます)
SSO URL:「https://abc.corp.local/sso/acs/」と入力(先述のVMware Workspace ONE Accessで設定した「シングルサインオン URL」と「受信先 URL」に同様のURLを入力)
セッション Cookie名:「SAML_app_ABC」と入力
セッション Cookieのタイムアウト:「1」と入力(検証目的のため、あえて短くしています)
SSLキー:「System-Default-Cert」を選択
VMware NSX ALB と VMware Workspace ONE Access を用いた SAML認証を挿入する設定は以上となります。

 

NSX ALB のVIPでSAML認証とユーザ可視化

ここまで設定したVMware NSX ALB と VMware Workspace ONE Access を用いた SAML認証の動作確認をしてみます。
以下のように、オンプレミスのWebサーバにアクセスし、SAML認証が動作するサンプルを以下の動画で見てみます。

 

クライアントは、「ABC Finance Dataのブックマーク」にアクセスをしたところ、Workspace ONE Accessの「認証認証ページ」にリダイレクトされ、認証が通ったあとにアクセスしたいページが表示されたことがわかります。

 

それでは、VMware NSX ALB のトランザクションログを見てみましょう。下段の図に表示されているログを、下から1つ1つ動作を解説していきます。

 

  1. 03/26 5:42:06 AMGET : https://abc.corp.local/finance/data.html へのクライアントからのアクセスに対して、 IdPに302リダイレクトされています
  2. 03/26 5:42:16 AMPOST  : https://abc.corp.local/sso/acs で、POSTリクエストを使用してクライアントから「仮想サービス」にSAML認証応答パラメータを送信し、初回にアクセスしたURIにリダイレクトされています
  3. 03/26 5:42:16 AM – 初回にアクセスしたURIに再度アクセスし、200 OK が返されていることがわかります。SSOの結果、クライアント情報に「User ID: [email protected]」という「ユーザID」もログに出力されていることがわかります。これは 前述の VMware Workspace ONE Access で設定した 「ユーザ名の値  : ${user.email}」の返り値となります。

 

 

SSOの結果、クライアント情報に「ユーザID」もログに出力されているため、ログ分析の「ユーザID」でアクセスしたユーザの分布も確認したり、ログのフィルター機能で「特定のユーザのアクセスログ」に絞り込んでログを確認することにも活用できたりします。システムトラブルのユーザ申告の際に、そのユーザでログ分析を行えることで、パケットキャプチャを行うことなくトラブルシュート・切り分けができてしまえそうですね。
まさに、VIPでSSOを用いることで、ユーザ識別も簡単に、そして運用での切り分け情報としてとても便利に使えそうなログではないかなと思います。

 

おまけ

SSOで識別できた「ユーザID」を、HTTPヘッダーに挿入してバックエンドサーバ(プールメンバー)に伝えることができます。ポリシーにある 「HTTP要求」のところで、アクションとして「ヘッダ追加」で「User Name」が選択できます。
これにより、SSOのユーザIDを任意のHTTPヘッダー名で挿入することができます。
上記の設定後のトランザクションログを見てみますと、「Headers sent to server」の「SAML-User-Email-Address」のヘッダーにクライアント情報である「[email protected]」といった「ユーザID」が挿入されていることがわかります。このように、HTTPヘッダーに挿入してバックエンドサーバ(プールメンバー)に「ユーザID」を伝えるような設定もGUIでシンプルに行えます。

 

まとめ

NSX Advanced Load Balancer を導入することで、SSOを含めたアプリケーションのセキュリティを大幅に強化することができます。基本となるロードバランス機能と一緒に、ぜひこうした認証の機構を一元化させるようなセキュリティ機能も有効活用してみてください。ちなみに、本ブログで紹介した「SAML認証」 を利用するためのNSX Advanced Load Balancer としての、追加ライセンスは不要です。Workspace ONE AccessをIdPとしてご利用いただく際には、Workspace ONE Access部分のライセンスは別途必要になりますが、既存のシステムに「SAML認証」 を導入するにあたり SPとIdP両方をVMwareから一括してサポートを提供させていただきます。これにより既存のシステムに「SAML認証」 を導入することもできたりします。ユーザ認証情報ベースで様々なセキュリティレベルを設定することができ、既存システムに対してもゼロトラストを取り入れることができますね。ぜひ、お試しください。

 

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

〜お知らせ〜

NSX-T Data Centerについて入門編から中級編まで各種セミナーも定期開催しております。より詳細についてご興味を持っていただけたお客さまはこちらも併せてご参加をご検討ください。

各種オンラインセミナーの開催日時はこちらから https://vmware-juku.jp/seminar/

  • VMware の新たな仮想ネットワークソリューションを聞いたみたい!という方はこちら

→ 2022年度!デモで分かりやすく解説!次世代ロードバランサとは(入門編)【オンライン開催】

 

※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs(HOL) という仕組みを無償でご提供しています。今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。

おすすめのHOLメニューはこちらから