Big-IPとADFSパート1 - ADFSファームの負荷分散

企業がクラウドへの移行を進める様子は、かつて開拓者たちが次々に幌馬車を仕立てて西への道を辿ったことを思い起こさせます。今クラウドに移行している企業はもはや開拓者とは呼べないかも知れませんが。クラウドへの集団移民が起こっているとまでは言えないものの、Office 365をはじめとしたクラウドベースのサービスを導入する企業が増えてきていることは事実です。

このような状況において、社外にあるリソースへのシームレスな、あるいは少なくとも比較的シームレスなアクセスを提供できるでしょうか？この回答のひとつにフェデレーションがあり、マイクロソフトを使っている企業ならADFS（Active Directory Federation Services）をその最新のソリューションとして利用することが可能です。この場合、ADFSサーバはセキュリティトークン サービスとして機能し、ディレクトリによって承認されるクライアントのシングルサインオン（SSO）を社外のリソースにも拡大します。クラウドベースのアプリケーションやフェデレーションの普及と歩調を合わせ、ADFSの役割も重要になってきています。以下にADFSサーバファームとADFS Proxyサーバファーム（社内に置いたADFSファームに外部からアクセスする場合に推奨）の典型的な展開シナリオを示しています。

警告：ADFSサーバファームを利用できない場合、フェデレーションによるリソースへのアクセスには制約が加わります。ハイアベイラビリティ、パフォーマンス、および拡張性を確保するためには、F5 Big-IPをLTM（Local Traffic Manager）と共に展開し、ADFSとADFS Proxyサーバファームの負荷分散を行います。F5のBig-IPは負荷分散とアプリケーション配信のための非常に優れた手段のひとつです。

それでは次に技術面を説明します。このブログのパート1では、ADFSとADFS Proxyサーバファームの負荷分散を目的とした、Big-IPのLTMモジュール（英語）の展開とコンフィグレーション設定について説明します。パート2ではBig-IPのAPM（英語）（Access Policy Manager）を利用することにより、この展開作業をはるかに簡素化し、改善できることを示します。

 

社内ADFSサーバファームの負荷分散

前提事項および製品展開のための資料 - この展開シナリオではADFSサーバファームがインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含むコンフィグレーション設定が展開ガイド（英語）に基づいて行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関する一般的な知識があることを想定しています。詳細やアドバイスが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。下図はADFSサーバファームの負荷をBig-IPによって分散する場合の典型的な（ただし簡略化された）プロセスフローを示しています。

 

 

1. クライアントがADFS対応の外部リソースへのアクセスを試みます。
2. クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。
3. クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。
4. ADFSサーバがアクティブディレクトリに対してクライアントを認証します。
5. ADFSサーバは、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーをクライアントに提供します。
6. クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。
7. クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。

 

仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（解読と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに外部向けのSSLとそれに伴う秘密鍵をインストールしておく必要があります。ただし後に説明するように、SSLブリッジングはこのタイプの展開では好ましい手段ではありません。その代わりとしてSSLトンネリング（パススルー）が利用されます。

ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。

負荷分散の手法 - 「Least Connections（メンバー）」方式を使用します。

プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、カスタマイズしたモニターを使用することができます。このモニターはADFSフェデレーションサービスが応答していることを保証します。またこのモニターは間隔とタイムアウト設定を高めて使用します。このカスタムhttpsモニターには、サービスのステータスを確認するためドメインの証明書を必要とします。この代わりとして標準的なhttpsモニターを使用することも可能です。

パーシステンス - このADFSシナリオでは、クライアントはセキュリティトークンの要求と受領のため、ADFSサーバとの間に単一のTCP接続を確立します。したがってパーシステンス プロファイルの指定は不要です。

SSLトンネリング（この方法を推奨） - SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバが使用します。

 

 

ADFS Proxyサーバファームの負荷分散

前提事項および製品展開のための資料 - この展開シナリオではADFS Proxyサーバファーム（英語）がインストールされ、該当するクレームプロバイダやリライングパーティとの間の信頼関係を含め、展開ガイド(英語)に基づくコンフィグレーション設定が適宜行われていることを前提としています。また読者にはBIG-IP LTMモジュールの管理に関して一般的な知識があることを想定しています。詳細やガイドが必要な場合はF5のサポートサイトASKF5（英語）を参照してください。

先のセクションでは、社内のADFSサーバファームを対象とした負荷分散の設定を行いました。このシナリオは社内ユーザにフェデレーション化されたSSOアクセスを提供する場合に機能します。しかし社外（つまりリモート環境）にいるユーザがフェデレーション化されたリソースにアクセスしようとする場合には対応できません。この場合にはADFS Proxyサーバが役立ちます。ADFS Proxyサーバを使用することにより、社外のユーザは社内のフェデレーションに対応したリソースに加え、Microsoft Office 365などのパートナーリソースにもアクセスすることができます。

1. クライアントがADFS対応の社外リソースへのアクセスを試みます。
2. クライアントはそのリソースのフェデレーションサービスにリダイレクトされます。
3. クライアントは社内のフェデレーションサービスにリダイレクトされます（リソースのフェデレーションサービスが信頼できるパートナーとして設定されていることが前提）。
4. ADFSProxyサーバはクライアントにカスタマイズ可能なサインオンページを表示します。
5. ADFSProxyは承認のためエンドユーザの証明書をADFSサーバに提示します。
6. ADFSサーバはそのクライアントをアクティブディレクトリについて認証します。
7. ADFSサーバはクライアントに対し、署名済みのセキュリティトークンとリソースパートナーへのクレームセットを含む認証クッキーを（ADFSProxyサーバ経由で）クライアントに提供します。
8. クライアントはリソースパートナーのフェデレーションサービスに接続し、そこでトークンとクレームが検証されます。該当する場合にはリソースパートナーが新しいセキュリティトークンをクライアントに提供します。
9. クライアントは新しい認証クッキーをそれに含まれるセキュリティトークンと共にリソースに提示してアクセスを行います。

 

仮想サーバとプールメンバー - 仮想サーバ（VIP）はポート443（https）を監視するよう設定されます。Big-IP SSLブリッジング（暗号化解除と再暗号化）に使用される場合、Big-IPと関連して作成されるクライアントSSLプロファイルに、パブリック側を向いたSSLとそれに伴う秘密鍵をインストールしておく必要があります。

 

 

 

 

ADFSはTransport Layer SecurityとSecure Sockets Layer（TLS/SSL）を必要とします。したがってプールのメンバーはポート443（https）を監視するよう設定されます。

 

 

 

 

 

負荷分散手法 - 「Least Connections（メンバー）」方式を使用します。

プールモニター - ADFSサービスとウェブサイト自体が応答していることを確認するため、ADFSProxyプールにはカスタマイズしたモニターを関連付けます。このモニターは間隔とタイムアウト設定を高めて使用します。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

「SSLトンネルを使うべきか否か」

SSLトンネリングを使用した場合、暗号化されたトラフィックがクライアントからエンドポイントであるファームのメンバーに直接流れます。またSSLプロファイルは使用せず、SSL証明書をBig-IPにインストールする必要もありません。ただしトンネリングを使用する場合、HTTP圧縮やウェブアクセラレーションなどを含む高度な最適化は行えません。クライアントの接続性やADFSサインオンページのカスタマイズなどの状況によっては、ADFSProxy展開にこのようなHTTP最適化が貢献する場合もあります。以下に2種類の選択肢（SSLトンネリングとSSLブリッジング）を比較します。

SSLトンネリング - この場合にはパケット分析または変更（例：圧縮、ウェブアクセラレーション）またはその両方を必要とするBig-IPプロファイルは意味を持ちません。さらにパフォーマンスを高めるためにはFast L4仮想サーバを使用します。SSLトンネリングを使用した場合の、Fast L4 Big-IP仮想サーバのコンフィグレーション例を下図に示します。

 

 

 

 

 

 

 

 

 

 

 

 

SSLブリッジング - SSLブリッジングを使用した場合、トラフィックは暗号化を解除され、次いでBig-IPデバイスにて再暗号化されます。これにより、接続の中のクライアントに対応する部分とプールメンバーに対応する部分の両方においてトラフィックにさらに機能を適用することが可能になります。SSLブリッジングを使用した場合の、標準的なBig-IP仮想サーバのコンフィグレーション例を下図に示します。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

標準的な仮想サーバのプロファイル - ADFSProxy仮想サーバのプロファイルのリストを下表に示しています。

プロファイルのタイプ	コメント
パーシステンス	仮想サーバにはデフォルトのクッキーパーシステンスプロファイルを関連付け
SSLクライアント	パブリック側を向いたSSLとそれに伴う秘密鍵をBig-IPにインストール。  これによりBig-IPでのトラフィックのSSL終端が容易に
SSLサーバ	仮想サーバにはデフォルトの「serverssl」プロファイルを関連付け
プロトコル	tcp-lan-optimizedプロファイルを仮想サーバのサーバ側に関連付け tcp-wan-optimized  プロファイルを仮想サーバのサーバ側に関連付け
OneConnect	仮想サーバにはデフォルトのoneconnectプロファイルを関連付け
HTTP	仮想サーバにはデフォルトのHTTPプロファイルを関連付け
HTTP圧縮	wan-optimized-compressionプロファイルを仮想サーバに関連付け
ウェブアクセラレーション	optimized-cachingプロファイルを仮想サーバに関連付け

 

これでパート1は終了です。この文の草稿を読んでコメントを提供してくれた、Insightの子会社であるEnsynch（英語）のケビン ジェイムズ、デイビッド ランデル、およびルツ ミューラー ヒッパーに対し、マイクロソフトのグローバルパートナーシップを担当するF5ビジネス開発チームと共に心から感謝を捧げます。

Big-IPとADFSパート2「APM - ADFSProxyに代わる選択肢」をお楽しみにお待ちください。