Windows AzureのAppFabricは、2011年10月現在「サービスバス」「アクセスコントロール」「キャッシュ」の3つのサービスが利用できる。前回は、手始めにAppFabricが利用できるように「サービス名前空間」を設定し、サンプルプログラム「Echo」を使って、コンソール画面から「サービスバス」を経由した通信が可能なことを確認した。今回はシングルサインオンを実現する「アクセスコントロール」を、Windows Azure上にデプロイしたWebアプリケーションから利用できることを確認する。
クレームベース認証を行うアクセスコントロール
Windows Azure AppFabricの「アクセスコントロール」は、Webアプリケーションやオンプレミスのアプリケーションから「シングルサインオン」を実現するためのサービスを提供する。つまり、ユーザーがすでにGoogleやWindows Live IDのアカウントを取得していれば、新規アカウントの登録といった煩雑な作業をすることなく、すぐサービスが利用できるようになる。
この「アクセスコントロール」において、重要な役割を果たすのが「クレームベース認証」と呼ばれる認証方式だ。クレームベース認証とは、ユーザーIDの提供者である「IDプロバイダー（GoogleやWindows Live IDなど）」、サービスを提供するアプリケーションである「リライングパーティー」、そし「てユーザー（アプリケーションの利用者）」からなるモデルだ（図1）。
「クレームベース認証」では、「Security Token Service（STS）」という機能を使う。STSとは、ユーザー認証トークンである「セキュリティトークン」を生成するサービスのことで、この中にIDプロバイダーが認証したユーザー情報（これを「クレーム」と呼ぶ）が含まれており、リライングパーティーは、この「クレーム」を使いサービス提供に必要なユーザー情報を取得する。
ただし「セキュリティトークン」は、IDプロバイダーからユーザーやリライングパーティーに直接渡るわけでない。いったん「フェデレーションプロバイダー」へ渡り、フェデレーションプロバイダーのSTSが生成したセキュリティトークンを使いリライングパーティーへアクセスする。
このように「フェデレーションプロバイダー」は、IDプロバイダーと信頼関係を結びつつ、かつリライングパーティーとも信頼関係を結んでいる。そのため、仮にIDプロバイダーの「クレーム」が異なったフォーマットでも、その違いを吸収することが可能になる。このフェデレーションプロバイダーを提供するサービスこそが、Windows Azure AppFabricの「アクセスコントロール」の役割である。
