次の方法で共有


ASP.NET Web API

Windows Azure AD と Microsoft OWIN コンポーネントで ASP.NET Web API をセキュリティ保護する

Vittorio Bertocci

Web API の役割が重要になるにつれ、機密データや操作が公開されるおそれがある価値の高いシナリオで API を安心して使えるようにするニーズも高まっています。

業界の動向は、OAuth 2.0 標準を使用した REST API のセキュリティ保護ソリューションへと明らかに収束しつつあります。しかし実際には、このソリューションでは、プロジェクト レベルで行う必要がある作業についての詳しいガイダンスが提供されていません。さらに、通信のセキュリティ保護を目的とした Microsoft .NET Framework の既存のクラスとツールは、特定のアプリケーションの種類 (ポストバック ベースの Web UX アプリケーション) と連携するように設計されているため、Web API や Web API が実現するマルチクライアント シナリオには適していません。その結果、Web API のセキュリティ保護は非常に技巧を要求される作業になっています。必ずしも安全が確保されないわけではありませんが、ソリューションによる違いが大きいために、必要なカスタム コードがあまりに多くなっています。

Visual Studio 2013 のリリースにより、これらの問題はすべて過去のものとなりました。このエディションでは、革新的な ASP.NET ツールと、Microsoft Open Web Interface for .NET (OWIN) コンポーネントにより提供され、Web API の保護を簡略化するセキュリティ ミドルウェアが導入されています。新しい ASP.NET ツールとテンプレートを使用すると、Windows Azure Active Directory (AD) に認証を直接委託するよう Web API プロジェクトを構成して、必要なコードをローカル プロジェクトにも Windows Azure AD の対応するエントリにも生成できます。

この記事では、このような Visual Studio 2013 の新機能を利用して、Windows Azure AD によってセキュリティ保護された単純な Web API を作成する方法を説明します。また、API の動作を確認できるテスト クライアントの作成方法を説明し、このシナリオを掘り下げてさらに詳しく調査する場合の出発点となる、背後のしくみについても紹介します。

資格情報をお願いします

認証とは、呼び出し元に対して、サーバーにメッセージを送るときに、呼び出し元の ID を検証したり属性を取得したりできるなんらかの資格情報を含めるように求めることです。その後、サーバーでその情報に基づいて承認します。つまり、アクセスを許可するかどうか、および許可する期間を判断します。

多くのリソースでは、ほとんどの認証機能を外部サービス プロバイダー (通称、"機関" または "ID プロバイダー") にオフロードしています。これらのプロバイダーは、ユーザーのオンボード、資格情報の割り当て、ライフサイクル フロー (パスワードの回復など) の処理、ユーザー認証用 UI の提供、複数のプロトコル経由での資格情報の検証、複数の認証要素の管理、不正行為の検出など、重要なタスクを担っています。

これらの機能以外の唯一の認証処理は、特定の機関で認証が成功したかどうかを確認することだけです。この処理では通常、セキュリティ トークン (認証が成功すると機関から呼び出し元に発行される少量のデータ) を確認します。

一般的にセキュリティ トークンは、特定の形式に従って作成され、発行機関を明確に特定できるキーでデジタル署名され、トークンとターゲット リソースを一意に結び付けるデータが含まれています。リソースでは、要求を受け取ったら、対応するトークンを探します。必要な検証属性に一致するトークンが見つかれば、呼び出し元が認証されます。

このレベルの詳細さでは、パターンが非常に包括的なため、さまざまな認証アプローチを表すことがあります。この記事では、おおよその役割を具体的な実体に割り当てることで、今回のシナリオにこのパターンを応用します。

リソース: 今回のリソースは、セキュリティ保護する必要がある ASP.NET Web API 2 プロジェクトです。さらに細かく認証要件を適用することもできます。たとえば、アクションの一部をセキュリティ保護するよう定義して、他のアクションは匿名の呼び出し元を受け入れるままにできます。

機関: 今回は、Web API を構成を構成することで、すべての Windows Azure AD (Windows Azure サブスクライバーが利用できる、サービスとしてのプラットフォーム (PaaS)) に認証ニーズをオフロードします。Windows Azure AD は、クラウド ベースのアプリケーション ワークロードをサポートするよう特別に設計されています。サービスは、ユーザー (属性と資格情報) についての情報と組織構造についての情報を保持します。サービスのデータは、Windows Server Active Directory と同期することも、オンプレミス インフラストラクチャを必要とせずにクラウドだけに保存することもできます。

ほぼすべてのオンライン マイクロソフト サービス (Office 365、Intune、および Windows Azure) では、認証とディレクトリのニーズに応じて Windows Azure AD を利用しています。オープン標準と一般的なプロトコルのサポートのおかげで、事実上あらゆるアプリケーション (Web UX、Web API、ネイティブ クライアント、サーバー間など) やプラットフォームから Windows Azure AD に接続できます。以降のセクションでは、Windows Azure AD にアプリケーションを登録して OAuth 2.0 エンドポイントを利用する方法を示します。

トークン形式と検証: OAuth 2.0 仕様では、トークン形式は特に定められていませんが、REST シナリオでは JSON Web Token (JWT) 形式 (bit.ly/14EhlE8、英語) が事実上の標準になっています。Windows Azure AD と Microsoft OWIN コンポーネントは、どちらも OAuth 2.0 フローでの JWT 形式をサポートしています。ここでこの点を取り上げている主な目的は、背景知識を提供するためです。JWT の取得と検証のしくみがすべてミドルウェアで処理されるため、トークン形式はアプリケーション コードに対して透過的です。

クライアント: リソースで認証の処理に機関を使用すると、リソースとクライアントが効果的に分離します。ユーザー (とクライアント アプリケーション) がトークンを取得する方法が、ユーザーと機関の間で扱われるようになります。これによってコードの保守性は向上しますが、API の動作を確認するには、やはりクライアントを設定する必要があります。この記事では、Web API のネイティブ クライアントを Windows Azure AD に登録する方法について説明します。また、Windows Azure AD Authentication Library (ADAL) を使用して、.NET リッチ クライアント アプリケーションで、Windows Azure AD に対してユーザーを認証できるようにし、トークンを取得して Web API の呼び出しをセキュリティ保護できるようにする方法を説明します。

図 1に、今回構築するソリューションのさまざまな要素を示します。現時点でよくわからない用語があっても問題ありません。どの用語も、ソリューションの開発について説明していく中で解説します。


図 1 エンドツーエンド ソリューションのアーキテクチャ

Web API プロジェクトを作成する

Web API プロジェクトを作成するには、Visual Studio 2013 の新しい ASP.NET ツールとテンプレートを使用します。Visual Studio を開いて、新しい ASP.NET Web アプリケーション プロジェクトを作成します。新しいプロジェクトのダイアログ ボックスで、Web API テンプレートを選択し、[認証の変更] ボタンをクリックします。

Web API の既定で選択できる認証スタイルが表示されます (図 2 参照)。ここでは [組織アカウント] を選択します。これを選択すると、Windows Azure AD を機関として使用できます (すべてのオプションの詳細については、bit.ly/1bhWngl(英語) を参照してください)。ここでの目標は、ID 管理の観点から重要な Web API の特徴について情報を収集し、認証を処理するよう構成する対象の Windows Azure AD インスタンス (通称 "テナント") を判断することです。


図 2 組織アカウントの認証ダイアログ ボックス

最初のドロップダウン ボックスでは、アプリケーションを使用する Windows Azure AD テナントが (基幹業務アプリケーションでよく見られるように) 1 つだけなのか、(サービスとしてのソフトウェア (SaaS) アプリケーションと聞いて想像するように) 複数なのかを指定します。通常、社内の従業員が使用するアプリケーションの場合は [単一の組織] を選択し、複数企業のユーザーがアクセスするアプリケーションの場合は [複数の組織] を選択します。とは言え、これらのオプションを 2 つとも使用できるのは、今のところ ASP.NET Web フォーム アプリケーションと ASP.NET MVC アプリケーションだけです。現在、Web API プロジェクト テンプレートでは [単一の組織] オプションのみがサポートされています。

[ドメイン] ボックスには、アプリケーションを登録する Windows Azure AD テナントを指定します。通常は Windows Azure サブスクリプションに関連付けられたエンタープライズ ディレクトリを指定しますが、管理資格情報があればどのディレクトリでもかまいません (後で詳しく説明します)。作成時には、どの Windows Azure AD テナントにも、3 レベルのドメイン (yourorganization.onmicrosoft.com 形式) を 1 つ関連付けます。通常は、既に所有している 1 つ以上のドメインにテナントを関連付けます。図 2 の例では、私個人のドメイン cloudidentity.net(英語) を使用しています。

[アクセス レベル] ボックスには、ディレクトリに対するアプリケーションのアクセス権を指定します。既定値の [シングル サインオン] の場合、ディレクトリからアプリケーションにトークンを発行できます。これは、アプリケーションが登録されていることを確認する単純な手段です。認証が成功した場合でも、登録されていないアプリケーションには機関からトークンが発行されません。

他のアクセス レベルには [ディレクトリ データの読み取り] と [ディレクトリ データの読み取りと書き込み] があります。それぞれ、アプリケーションでディレクトリの照会とディレクトリのコンテンツの変更を実行できるようになります。これを実現するのが Graph API です。Graph API は、HTTP スタックを使用するあらゆるプラットフォームのアプリケーションがディレクトリへの委任アクセス権を取得できるようにすることを目的とした、REST ベース プログラム インターフェイスです。今回はアクセス レベルを既定の [シングル サインオン] のままにし、Web API プロジェクトでの Graph については説明しません。しかし、Graph は Windows Azure AD の非常に強力な機能です。Windows Azure AD Graph API の詳細については、msdn.microsoft.com/ja-jp/library/windowsazure/hh974476.aspxを参照してください。

Windows Azure AD テナントに関連付けられたドメインを入力したら、[OK] をクリックしてプロジェクトを生成します。ツールによって、次の 2 つのタスクが実行されます。

  1. 選択した Windows Azure AD テナントにアクセスし、作成しようとしているアプリケーションの説明エントリを追加する。
  2. Web API プロジェクトのコードを作成する。また、必要なセキュリティ ミドルウェアを Microsoft OWIN コンポーネントから追加して Windows Azure AD 認証を処理し、必要な初期化コードを生成して、選択した Windows Azure AD テナントに応じて受信トークンを検証する。

最初のタスクは Graph API で実行されます (Visual Studio 自体が Graph API のクライアントです)。作成しようとしているアプリケーションの説明エントリをディレクトリに追加するには、API で、ディレクトリへの書き込みに必要な特権があることを証明するトークンを、ディレクトリから取得する必要があります。これが、[OK] をクリックすると、Visual Studio に図 3の認証ダイアログ ボックスが表示される理由です。


図 3 アカウント サインインの認証ダイアログ ボックス

開発者は、ディレクトリの管理資格情報を入力するだけで十分です。ツールによって、要求した操作の実行に必要な特権があることが確認されます。[OK] をクリックすると、Visual Studio が Windows Azure AD に接続し、プロジェクト ファイルが生成されます。

これで完全に構成済みの Web API が完成したので、特定の Windows Azure AD テナントの呼び出し元だけがアクセス権を取得できるようにする準備ができました。それでは、詳しく見ていきましょう。

ソリューション エクスプローラー ウィンドウに移動すると、ルートに Startup.cs というファイルがあります。先月号の Howard Dierking による記事「Katana プロジェクトの概要」(msdn.microsoft.com/magazine/dn451439) をお読みの方は、このファイルのクラスがアプリケーションの起動時に呼び出されることをご存じでしょう。今回、実装は単純です。

public partial class Startup
 {
   public void Configuration(IAppBuilder app)
   {
     ConfigureAuth(app);
   }
 }

通例から、ConfigureAuth メソッドは、App_Start ソリューション フォルダー内のクラスで定義されていると考えられます。実際、このメソッドは Startup.Auth.cs ファイルで定義されています。次に例を示します。

public partial class Startup
 {
   public void ConfigureAuth(IAppBuilder app)
   {
     app.UseWindowsAzureActiveDirectoryBearerAuthentication(
       new WindowsAzureActiveDirectoryBearerAuthenticationOptions
       {
         Audience = ConfigurationManager.AppSettings["ida:Audience"],
         Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
       });
   }
 }

app.Use* という名前付け規則から、メソッドで OWIN パイプラインにミドルウェア実装を追加していることがわかります。この例では、追加されたミドルウェアで受信要求を検査して、HTTP ヘッダーの Authorization にセキュリティ トークンが含まれているかどうかを確認します。これが、OAuth 2.0 のベアラー トークン仕様に従って要求をセキュリティ保護する方法です (bit.ly/W4OqA3(英語) 参照)。トークンが見つかった場合は、多数の標準的なチェックでトークンを検証します。チェック内容は、意図した機関によって発行されたトークンかどうか、転送中にトークンが変更されていないかどうか、トークンの有効期限が切れていないかどうかなどです。

トークンに問題がなければ、ミドルウェアはトークンのコンテンツをプリンシパルに反映し、プリンシパルを現在のユーザーに割り当てて、パイプラインの次の要素に制御を渡します。トークンがチェックに合格しなかった場合、ミドルウェアは適切なエラー コードを返します。

トークンがない場合、ミドルウェアはプリンシパルを作成することなく呼び出しを処理します。一般的には認証フィルターの形式をとる認証ロジックで、プリンシパルの有無 (とそのコンテンツ) を利用して、要求に対応するか、アクセスを拒否するかを判断します。

ミドルウェアに渡す 1 つのパラメーター (WindowsAzureActiveDirectoryBearerAuthenticationOptions) は、トークンの有効性を判断するための設定を指定します。このパラメーターでプロジェクト作成時に未加工の値をキャプチャして、web.config ファイルに格納します。Audience の値は、Windows Azure AD に Web API を伝えるための識別子です。Audience の値が異なるトークンは他のリソースを表すので拒否する必要があります。

Tenant プロパティは、認証のアウトソーシングに使用されている Windows Azure AD テナントを示します。ミドルウェアではこの情報を使用してテナントにアクセスし、トークンの有効性を判断するための他のすべてのプロパティ (トークンのシグネチャの検証に使用するキーなど) を読み取ります。

これらの自動生成された数行のコードがあれば、Windows Azure AD で呼び出し元を認証できます。Web API プロジェクトで行う他の手順は、保護するメソッドを [Authorize] で修飾することだけです。これを ValuesController のすべてのメソッドに追加します (説明を簡潔にするため、テンプレートに設定されている既定のコントローラーを使用しています)。

それでは、意図したとおりに Web API が動作しているかどうかを確認するには、どうしたらよいでしょうか。最も簡単な方法は、テスト クライアントを作成することです。

ネイティブ クライアントを登録する

Windows Azure AD では登録されていない Web API に対してトークンが発行されないのと同様に、Windows Azure でも、トークンを要求するクライアントがすべて登録されている必要があります。特定の Web API のトークンを取得するには、登録されたクライアントに Windows Azure AD のその Web API に対するアクセス権が明示的に付与されている必要があります。このようなデザイン時の設定は、ユーザーが認証を試みる前に設定しておく必要があります。それでは、Windows Azure ポータルを使用してクライアント アプリケーションを登録し、作成した Web API とアプリケーションを関連付ける許可を作成する方法を説明しましょう。

まず、Windows Azure ポータルにアクセスします。先ほど使用したのと同じアカウントで認証します。時間を節約するために、Windows Azure AD テナントの Windows Azure ポータルに直接移動します。この URL には、通常のポータル アドレスにテナント ドメインを追加するとアクセスできます。私の場合は、https://manage.windowsazure.com/cloudidentity.net です。

テナント固有の URL に移動する方が、共通ログイン ページの [組織アカウントでサインインする] ボックスを探すよりも時間を節約できます。使用している Windows Azure AD が Windows Azure サブスクリプションの管理者または共同管理者でない場合は、通常の資格情報 (Microsoft アカウントまたは他の組織のエンティティ) を使用してポータルにサインインする必要があります。

ポータルが読み込まれたら、利用可能なサービスの一覧から [ACTIVE DIRECTORY] を選択し、自分のディレクトリをクリックして、[アプリケーション] タブをクリックします。新しい Web API プロジェクトのエントリを含む、すべての作成済みアプリケーションの一覧が表示されます。新しいエントリを作成するには、ページ下部のコマンド バーにある [追加] ボタンをクリックします。図 4の画面が表示されます。技術的には、ほぼ全種類のアプリケーションを定義でき、そのアプリケーションが Web API の有効なクライアントになります。[NATIVE CLIENT APPLICATION] (ネイティブ クライアント アプリケーション) をオンにして、次の画面に進みます。


図 4 Windows Azure Active Directory ポータルでのアプリケーション追加ウィザードの第 1 段階

次の最終画面では、アプリケーションのリダイレクト URI を入力するよう求められます。この URI は、OAuth 2.0 トークン取得フローで、認証プロセスの対話型の部分が終了したことを表す信号を呼び出し元に送るために使用される、単なる識別子です。残りのトークン取得プロセスは、ユーザー入力なしで進行します。開発しているネイティブ クライアントのプラットフォームによっては、開発者はさまざまな制約に対処する必要に迫られることがあります。たとえば、Windows ストア アプリでは、特定の機能 (msdn.microsoft.com/ja-jp/library/windows/apps/jj856909.aspx参照) を使用する場合、ms-app:// プロトコル スキーマを使用する必要があります。

今回は、従来の .NET デスクトップ アプリケーションを作成します。このアプリケーションはかなり寛容なので、有効な URI なら何でも使用できます。ここではこのクライアントの目的を覚えやすいよう、https://cloudidentity.net/myWebAPItestclient を使用しました。

アプリケーションのエントリが完成すると、図 5 のページが表示されます。


図 5 クイック スタート ページ

[Update Your Code] (コードの更新) セクションには、クライアント アプリケーションを作成するときに必要になる情報が提供されます。この情報には、リダイレクト URI とクライアント ID (単純な識別子) の設定も含まれます。これらは、機関へのトークン要求を作成するときに必要です。

[CONFIGURE ACCESS TO WEB APIS] (Web API へのアクセス構成) セクションでは、ポータル領域へのリンクが提供されます。このポータル領域で、クライアントがアクセスできる API を指定できます。リンクをクリックすると、アプリケーションのプロパティ ページに移動します (図 6参照)。ページ下部には、クライアントがアクセスする Web API を指定できるドロップダウン ボックスがあります。このドロップダウン ボックスには、ユーザーが定義したアプリケーションと組み込み API (Windows Azure AD Graph API) の両方が表示されていることに注目してください。


図 6 Windows Azure Active Directory ポータルのネイティブ クライアント アプリケーション プロパティ ページ

Web API プロジェクト エントリを選択し、[Save] (保存) をクリックします。これで、サービスのトークンをクライアントが取得できるようにするための Windows Azure AD の準備がすべて整いました。このページのデータの一部は後で必要になるので、ブラウザーでこのページを開いたままにしておきます。

単純なクライアント プロジェクトを作成し、Web API をテストする

ようやく、テスト クライアントを作成して認証済み Web API を試す準備ができました。HTTP スタックを提供するプラットフォーム上であれば、ほとんどあらゆる種類のクライアントを作成できます。トークンを取得して管理するタスクを簡単にするために、マイクロソフトでは、ADAL というテクノロジを用意しており、認証プロトコルに精通していなくても簡単に (Windows Azure と Windows Server 両方の) Active Directory 認証を実行できます。

Microsoft .NET Framework 用にはライブラリがリリースされていて、Windows ストアでは開発者向けプレビューを利用できます (チュートリアルとこのシナリオの Windows ストア アプリへの実装方法については、bit.ly/17YtYVg(英語) を参照してください)。最終的には、すべての主要クライアント プラットフォームを対象としたバージョンが揃う予定です。

.NET バージョンが既に一般公開されているので、今回はこれを使用します。さまざまなスタック間での構文の違いを除けば、.NET バージョンで学んだことは、他の種類のプラットフォームやアプリケーションにも簡単に応用できます。待ちきれない方は、今回説明するシナリオでお伝えする内容はすべてオープン標準に準拠していて、詳しいドキュメントがを利用できることを覚えておいてください。トークン要求ロジックのコーディングはとても簡単です。Windows Phone 8 を使用する例については、bit.ly/YatATk(英語) を参照してください。

今回のプロジェクトは、同じソリューション内の新しい Windows Presentation Foundation (WPF) アプリケーション用ですが、ユーザーが対話的に実行することを目的とした種類のプロジェクトならどれでも選択できます。プロジェクトを作成したら、Web API 呼び出しロジックをトリガーするボタンとクリック イベント ハンドラーを追加します。

ADAL は NuGet パッケージとして配布されています。これをクライアント プロジェクトに追加するには、Visual Studio の [ツール] メニューからパッケージ マネージャー コンソールを開いて、「Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 1.0.0」と入力します。これで、図 7のコードがクリック イベント ハンドラーに追加されます。

図 7 クリック イベント ハンドラーに追加するコード

private async void btnCall_Click(object sender, RoutedEventArgs e)
 {
   // Get token
   AuthenticationContext ac = new AuthenticationContext(
     "https://login.windows.net/cloudidentity.net");
   AuthenticationResult ar =
     ac.AcquireToken("https://cloudidentity.net/WindowsAzureADWebAPITest",
     "a4836f83-0f69-48ed-aa2b-88d0aed69652",
     new Uri("https://cloudidentity.net/myWebAPItestclient"));
   // Call Web API
   string authHeader = ar.CreateAuthorizationHeader();
   HttpClient client = new HttpClient();
   HttpRequestMessage request = new HttpRequestMessage(
     HttpMethod.Get, "https://localhost:44353/api/Values");
   request.Headers.TryAddWithoutValidation("Authorization", authHeader);
   HttpResponseMessage response = await client.SendAsync(request);
   string responseString = await response.Content.ReadAsStringAsync();
   MessageBox.Show(responseString);
 }

コードが難しそうに見えても、心配ありません。これからすべて説明します。

1 行目では新しい AuthenticationContext を初期化しています。アプリケーションのコードの AuthenticationContext インスタンスは、連携先機関を表しています。この例では、機関は https://login.windows.net/\[mydomain\] という形式の URI で表される Windows Azure AD テナントです。Active Directory フェデレーション サービス (AD FS) サーバーのアドレスを渡してオンプレミス ディレクトリに接続する際にも、同じロジックを使用します (詳細については、bit.ly/1d553F0(英語) を参照してください)。

2 行目では、AuthenticationContext にトークンを要求しています。シナリオやアプリケーションの種類によって必要なパラメーターが異なるため、トークン要求の作成にはさまざまな方法があります。今回は、トークンを要求するリソースが Web API であることを指定する必要があります。そのため、Windows Azure AD エントリの識別子を渡します。これは、Web API プロジェクトの Audience と同じ値です。次に、トークンの要求元がネイティブ クライアントなので、ブラウザーで開いたままのアプリケーション構成ページに表示されているクライアントの ID とリダイレクト URI を渡す必要があります。

これでトークンの取得に必要な作業は完了です。残りのコードでは、OAuth 2.0 仕様に従ってこのトークンを適切な HTTP ヘッダーに配置し、実際の呼び出しを実行しています。

それでは、ソリューションを試してみましょう。すべてのプロジェクトを同時に開始するようにソリューションを変更したら、F5キーを押します。AcquireToken の呼び出しまで実行すると、図 8の認証ダイアログ ボックスが表示されます。ADAL によって、適切なエンドポイントに接続され、UI コードを記述しなくてもサーバーから提供される認証エクスペリエンスがポップアップ ダイアログ ボックスにレンダリングされます。


図 8 Active Directory Authentication Library 認証ダイアログ ボックス

ディレクトリ テナントの有効なユーザーの資格情報を入力すると、トークンが返されます。以降のコードは、要求ヘッダー内の Web API に対するトークンを表します。セキュリティ ミドルウェアによってトークンが検証されます。すべての検証パラメーターが一致するため、結果と共に HTTP 状態コード 200 が返され、このシナリオの概念実証が問題なく終了します。

試しに、もう一度ボタンをクリックしてみましょう。今度はメッセージが表示されることなく、すぐにトークンが返されます。これは、トークンを追跡する組み込みのトークン キャッシュが ADAL に備わっているためです。また、期限の切れたトークンは、可能な限り自動的に更新されます。

発展の可能性

この記事では、Web API、Microsoft OWIN コンポーネント、Windows Azure AD、および ADAL を使用して実現できることについてほんの概要を説明したにすぎません。Windows Azure AD から発行されるトークンは、単なる認証の証拠ではありません。トークンには、ユーザー プリンシパルから簡単にアクセス可能で、高度な認証ロジックに使用できる、大量のユーザー情報が含まれています。認証プロセスは、今回説明した単なるユーザー名とパスワードからはるかに拡張できます。

複数の認証要素からフェデレーション シナリオでのシームレスなシングル サインオンまで、可能性は無限にあります。Graph API と統合すると、さらに豊富な機能を利用できるようになります。また、現在認証されているユーザー情報以外の情報も、単純なユーザー選択機能から高度な組織構造クロールまでディレクトリに照会できます。

これらの機能は、クラウド ベース Web API の機能に追加できます。今までは、このような機能は会社のファイアウォールの内側のオンプレミスで実行する必要がありました。また、Windows Server Active Directory でも同様のコードを使用できます。これは、クラウドとオンプレミスの機能が対称関係にあることを示す明白な例の 1 つです。

もちろん、コードを 1 行も変更せずに Web API を Windows Azure に発行することもできます。その場合も、認証機能は機能し続けます。変更する必要があるのは、クライアント プロジェクトだけです。サービスの URL は新しいアプリケーションの場所に応じて変わります。しかし、リソース識別子をリソースの物理アドレスに関連付ける必要がないので、トークンを取得するロジックはまったく変更する必要がありません。

Vittorio Bertocci は、Windows Azure AD チームの主任プログラム マネージャーを務めており、開発者エクスペリエンスを担当しています。ID と開発に関する書籍、主要カンファレンスでのセッション、ブログ (cloudidentity.com、英語)、および Twitter フィード (twitter.com/vibronet、英語) を通じた長年のエバンジェリストとしての活動から、Bertocci は開発者コミュニティで有名です。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Howard Dierking と Daniel Roth に心より感謝いたします。
Howard Dierking は Windows Azure フレームワークとツール チームのプログラム マネージャーを務めており、ASP.NET、NuGet、および Web API に重点的に取り組んでいます。以前には、MSDN マガジンの編集長の経験や、Microsoft Learning のデベロッパー認定プログラムを指揮したことがあります。マイクロソフトに勤務する前は、分散システム専門の開発者兼アプリケーション アーキテクトとして 10 年間仕事に取り組んでいました。

Daniel Roth は Windows Azure アプリケーション プラットフォーム チームのシニア プログラム マネージャーとして、現在は ASP.NET Web API に携わっています。ASP.NET に携わるまでの間は、WCF が .NET Framework 3.0 に初めて同梱された当初から WCF に取り組んできました。彼の情熱は、フレームワークをシンプルで使いやすくして、ユーザーを喜ばせることに向けられています。