PR

 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)。

図1●クレームベース認証<br>ユーザーからのログイン要求により、IDプロバイダーは認証を行い、フェデレーションプロバイダーにセキュリティートークン(クレーム)を渡す。フェデレーションプロバイダーは、受け取ったトークンを基に、新たなセキュリティトークンを発行する。ここからリライングパーティは、ユーザーのクレーム情報を受け取り、ユーザーはトークンを取得してリライングパーティにアクセスする。
図1●クレームベース認証
ユーザーからのログイン要求により、IDプロバイダーは認証を行い、フェデレーションプロバイダーにセキュリティートークン(クレーム)を渡す。フェデレーションプロバイダーは、受け取ったトークンを基に、新たなセキュリティトークンを発行する。ここからリライングパーティは、ユーザーのクレーム情報を受け取り、ユーザーはトークンを取得してリライングパーティにアクセスする。
[画像のクリックで拡大表示]

 「クレームベース認証」では、「Security Token Service(STS)」という機能を使う。STSとは、ユーザー認証トークンである「セキュリティトークン」を生成するサービスのことで、この中にIDプロバイダーが認証したユーザー情報(これを「クレーム」と呼ぶ)が含まれており、リライングパーティーは、この「クレーム」を使いサービス提供に必要なユーザー情報を取得する。

 ただし「セキュリティトークン」は、IDプロバイダーからユーザーやリライングパーティーに直接渡るわけでない。いったん「フェデレーションプロバイダー」へ渡り、フェデレーションプロバイダーのSTSが生成したセキュリティトークンを使いリライングパーティーへアクセスする。

 このように「フェデレーションプロバイダー」は、IDプロバイダーと信頼関係を結びつつ、かつリライングパーティーとも信頼関係を結んでいる。そのため、仮にIDプロバイダーの「クレーム」が異なったフォーマットでも、その違いを吸収することが可能になる。このフェデレーションプロバイダーを提供するサービスこそが、Windows Azure AppFabricの「アクセスコントロール」の役割である。

この記事は会員登録で続きをご覧いただけます

日経クロステック登録会員になると…

新着が分かるメールマガジンが届く
キーワード登録、連載フォローが便利

さらに、有料会員に申し込むとすべての記事が読み放題に!
有料会員と登録会員の違い