BIG-IPとADFSパート3 - 「ADFS、APM、およびOffice 365シッククライアント」

パート3があるという話はしていませんでした。しかしこのシリーズの内容はパート2で止めておくには面白すぎますし、実はカバーしておくべき重要なセクションがもうひとつありました。

まず、パート1と2について簡単に復習します。パート1ではADFSとADFSProxyファームの負荷分散による、ハイアベイラビリティと拡張性の確保について説明しました。パート2では、ADFSProxyレイヤの代替としてのAccess Policy Manager（APM）（英語）を取り上げました。この方法はソリューションのセキュリティと柔軟性を高めるだけでなく、インフラストラクチャの簡素化にも貢献します。

このシリーズをフォローしていただいた方なら（たぶん）覚えておられるように、パート2ではOffice 365をユースケースとして、Big-IPとAPMがどのようにOutlook Web Access（OWA）へのSSOサインオンを実現するかを示しました。しかしOutlookとLyncクライアントを含むシッククライアント（thick client - アクティブなプロトコルとアクティブなプロファイル）の場合にはもう少し状況が複雑になります。以下にこれを説明します。

パッシブプロトコル - （Outlook Web App）

WS-Federationパッシブプロトコルを使うクライアントの（主としてブラウザベースの）プロセスは以下のとおりです。

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

上記のケースでは、ADFSはWS-FederationプロトコルとSAMLを使用しています。このタイプの接続は、一般にBIG-IPのAPMを使ってADFSへの接続をプロキシ化することによって大きく改善されます。

アクティブプロトコル - （OutlookおよびLyncクライアント）

OutlookやLyncのようなクライアント（外部クライアント）によるやり取りは少し異なります。この場合のプロセスはアクティブプロトコル、WS-Trust、およびSOAPを使用します。

1. クライアントがOffice 365リソースへのアクセスを試み、認証情報を提供します。
2. Office 365はMicrosoft Federation Gatewayに認証を求めます。
3. Microsoft Federation Gatewayはクライアントに代わってADFSサービスに連絡し、認証情報を提示します。
4. ADFSはクライアントの認証情報をアクティブディレクトリにより認証します。
5. ADFSはMicrosoft Federation Gatewayにトークンを提供します。
6. Microsoft Federation GatewayはOffice 365にトークンを提供し、クライアントによるリソースへのアクセスを可能にします。

簡単に言えば、クライアントがADFSにトークンを要求して取得するための作業を行う代わりに、Microsoft Federation GatewayがADFSとのやり取りを直接行います。クライアントはADFSとは接続しないため、APM（またはどのプロキシサービスも）は使用できません。

ここで問題が生じます。Big-IP APMの背後でADFSを展開している場合、シッククライアント（OutlookやLync）の認証のためMicrosoft Federation Gatewayが直接アクセスを行い、かつパッシブな接続（ブラウザベースと社内のLync）については事前認証を行えるようにするにはどうすれば良いでしょうか？これはiRuleを使うことにより簡単に解決できます。

APMはiRuleをバイパス

MS Federation Gatewayに直接アクセスできるよう、iRuleをひとつ作成し、それを本シリーズのパート2で作成したADFS仮想サーバに割り当てます。このiRuleはHTTP_REQUEST（英語）イベント（システムがHTTPリクエストのパーシングを行うことによって起動）を使ってURIを分析します。適切なリクエストを受領するとACCESS::disable（英語）コマンドが呼び出されてアクセスポリシーが無効になり、リクエストの通過が許可されます。サードパーティ製プロキシの要件についてはマイクロソフトが発行するガイドも参照してください。以下の基本的なiRuleを作成し、社外のADFS仮想サーバに割り当ててみてください。

   1: when HTTP_REQUEST {

   2:  

   3:   # For external Lync client access all external requests to the

   4:   # /trust/mex URL must be routed to /trust/proxymex. Analyze and modify the URI

   5:   # where appropriate 

   6:   HTTP::uri [string map {/trust/mex /trust/proxymex} [HTTP::uri]]

   7:  

   8:   # Analyze the HTTP request and disable access policy enforcement WS-Trust calls

   9:   if {[HTTP::uri] contains "/adfs/services/trust"} {

  10:     ACCESS::disable

  11:   }

  12:  

  13:   # OPTIONAL ---- To allow publishing of the federation service metadata 

  14:   if {[HTTP::uri] ends_with "FederationMetadata/2007-06/FederationMetadata.xml"} {

  15:     ACCESS::disable

  16:   }

  17:  }

以上です。単純明快ですね。ご自分で試してみてその結果を教えてください。ここでは社外からのアクセスを取り扱っているため、外部アクセスの識別とブロックのためのADFS 2.0のサポートについては触れませんでした。この高度な機能に関心がある場合はマイクロソフトが発行するガイド（英語）を参照してください。