セキュリティ保護された ASP.NET アプリケーションの構築 : 認証、認定、および通信のセキュリティ保護 第 10 章 Web サービス セキュリティ

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

November 2002
日本語版最終更新日 2003 年 3 月 17 日

適用対象:
    Microsoft® ASP.NET
    Microsoft® Internet Information Server
    Microsoft® Web Services Development Kit

全体の概要については、「セキュリティ保護された ASP.NET アプリケーションの構築」の開始ページを参照してください。

要約 : この章では、IIS と ASP.NET の基本的な機能を使用する、Web サービスのプラットフォーム レベルのセキュリティを重点的に説明します。メッセージ レベルのセキュリティについては、Microsoft では Web Services Development Kit を開発中です。この開発キットでは、Global XML Architecture (GXA) の一部である WS-Security という仕様に準拠したセキュリティ ソリューションを構築することができます。

目次

Web サービスのセキュリティ モデル
プラットフォーム/トランスポートのセキュリティ アーキテクチャ
認証および認定のしくみ
セキュリティの構成
認証用の資格情報を Web サービスに渡す
最初の呼び出し元のフロー
信頼されたサブシステム
システム リソースへのアクセス
ネットワーク リソースへのアクセス
COM オブジェクトへのアクセス
Web サービスでのクライアント証明書の使用方法
通信のセキュリティ保護
まとめ

この章では、認証、認定、および通信のセキュリティ保護の技術を開発、応用して、ASP.NET Web サービスや Web サービスのメッセージのセキュリティを保護する方法を説明します。また、Web サービスから見たセキュリティ、呼び出し元の認証方法および認定方法、Web サービスを通じてセキュリティ コンテキストをフローする方法も説明されています。さらに、クライアント側の観点から見た、サーバー側の認証をサポートするために資格情報と証明書を使用して Web サービスを呼び出す方法が説明されています。

Web サービスのセキュリティ モデル

Web サービスのセキュリティは、3 つのレベルで適用することができます。

• プラットフォーム/トランスポート レベル (ポイント ツー ポイント) のセキュリティ
• アプリケーション レベル (カスタム) のセキュリティ
• メッセージ レベル (エンド ツー エンド) のセキュリティ

それぞれの方法には、さまざまな長所や弱点があります。この長所や弱点を、ここから詳しく説明していきます。どの方法を選択するかは、メッセージのやり取りに必要なアーキテクチャおよびプラットフォームの特性によって大きく異なります。

メモ この章ではプラットフォーム レベルおよびアプリケーション レベルのセキュリティに重点を置いています。メッセージ レベルのセキュリティには、GXA (Global XML Web Services Architecture) と、特に WS-Security 仕様が対応しています。これが執筆された時点では、Microsoft はテクノロジ プレビュー版の Web Services Development Kit をリリースしたばかりです。この開発キットでは、WS-Security 仕様に準拠したメッセージ レベルのセキュリティ ソリューションを開発することができます。

プラットフォーム/トランスポート レベル (ポイント ツー ポイント) のセキュリティ

Web サービスのクライアントと Web サービスの 2 つのエンドポイント間のトランスポート チャネルは、ポイント ツー ポイントのセキュリティを確保するため使用できます。これを図 10.1 に示します。

図 10.1 プラットフォーム/トランスポート レベルのセキュリティ

プラットフォームのセキュリティは、企業のイントラネットなどで緊密に結合された Microsoft? Windows? オペレーティング システム環境を前提としていますが、このセキュリティを使用する場合の特徴を以下に示します。

• Web サーバー (IIS) は、基本認証、ダイジェスト認証、統合認証、および証明書認証を提供します。
• ASP.NET Web サービスは、ASP.NET の認証機能および認定機能の一部を継承します。
• SSL と IPSec の両方またはいずれかを、メッセージの整合性および機密性を確保するために使用することがあります。

どのような場合に使用するか

トランスポート レベルのセキュリティ モデルは単純で、よく知られており、主にインターネット ベースなど多くの事例に適しています。

トランスポート レベルのセキュリティの主な問題を以下に示します。

• セキュリティは、基礎となるプラットフォーム、転送メカニズム、およびNTLM や Kerberos などのセキュリティ サービス プロバイダに緊密に結合および依存することになります。
• セキュリティは、ポイント ツー ポイントで適用されます。複数のホップおよび中間のアプリケーション ノードを通じたルーティングには対応していません。

アプリケーション レベルのセキュリティ

この方法では、アプリケーションによってセキュリティが行われ、カスタムのセキュリティ機能が使用されます。次に、例を示します。

• アプリケーションは、カスタムの SOAP ヘッダーを使用してユーザーの資格情報を渡し、各 Web サービス要求を使用してユーザーを認証することができます。一般的な方法では、チケット (ユーザー名またはライセンス) をSOAP ヘッダーで渡します。
• アプリケーションには、ロールが含まれる独自の IPrincipal オブジェクトを生成する柔軟性があります。これは、カスタムのクラスか、.NET Framework に用意されている GenericPrincipal クラスである場合があります。
• アプリケーションは必要に応じて内容を暗号化しますが、これにはセキュリティで保護されたキー記憶領域が必要であり、開発者は適切な暗号化 API の知識を持っている必要があります。

これ以外の方法として、機密性と整合性を確保するために SSL を使用し、これをカスタムの SOAP ヘッダーと組み合わせて認証を実行することもできます。

どのような場合に使用するか

この方法は、以下の場合に使用します。

• 既存のアプリケーションで使用される、ユーザーおよびロールの既存のデータベース スキーマを利用する。
• データ ストリーム全体ではなく、メッセージを部分的に暗号化する。

メッセージ レベル (エンド ツー エンド) のセキュリティ

これは、最も柔軟性が高く強力な方法であり、GXA (特に WS-Security 仕様) で使用されます。図 10.2 は、メッセージ レベルのセキュリティを示しています。

図 10.2 メッセージ レベルのセキュリティ

WS-Security 仕様には、メッセージの整合性と機密性、単一のメッセージ認証を実現する SOAP メッセージングの拡張機能が記述されています。

• 認証は、セキュリティ トークンによって実現されています。このトークンは SOAP ヘッダーでフローされます。WS-Security では、特定のタイプのトークンは必要ありません。セキュリティ トークンには、Kerberos チケット、X.509 証明書、またはカスタムのバイナリ トークンが含まれていることがあります。
• 通信の安全性は、メッセージの整合性を保証するデジタル署名と、メッセージの機密性のための XML 暗号化によって確立されています。

どのような場合に使用するか

WS-Security は、異種の Web サービスが混在する環境で、セキュリティで保護されたメッセージをやり取りするためのフレームワークの構築に使用することができます。また、WS-Security は、エンドポイントおよび中間のアプリケーション ノードの両方の構成を直接管理できないさまざまな環境や状況に最適です。

メッセージ レベルのセキュリティには、以下の特徴があります。

• 基礎となるトランスポートから独立させることができます。
• 異種のセキュリティが混在するアーキテクチャが可能になります。
• エンド ツー エンドのセキュリティを実現し、中間のアプリケーション ノードを通じたメッセージ ルーティングに対応します。
• 複数の暗号化技術をサポートします。
• 否認不能性をサポートしています。

Web Services Development Kit

Web Services Development Kit には、セキュリティの管理と、ルーティングやメッセージ レベルの参照などのその他のサービスに必要な API が用意されています。このツールキットは、WS-Security などの Web サービスの最新規格に準拠しているため、この仕様に準拠するその他のベンダと相互運用が可能になっています。

詳細情報

• Web Services Development Kit および WS-Security 仕様の最新情報については、MSDN ライブラリの XML Developer Center ページを参照してください。
• WS-Specification の詳細については、WS-Security Specification Index Page を参照してください。
• GXA の詳細については、MSDN ライブラリの「GXA 入門」を参照してください。
• このトピックに関するディスカッションについては、MSDN ライブラリの GXA Interoperability Newsgroup (英語情報) を参照してください。

プラットフォーム/トランスポートのセキュリティ アーキテクチャ

ASP.NET Web サービス プラットフォームのセキュリティ アーキテクチャを図 10.3 に示します。

図 10.3 Web サービスのセキュリティ アーキテクチャ

図 10.3 は、ASP.NET Web サービスの認証および認定のメカニズムを示しています。クライアントが Web サービスを呼び出すと、以下の順序で認証イベントおよび認定イベントが発生します。

1. ネットワークからの SOAP 要求が受信されます。これに認証資格情報が含まれているかどうかは、使用されている認証の種類によって異なります。

2. IIS は、必要に応じて基本認証、ダイジェスト認証、統合認証 (NTLM か Kerberos)、または証明書認証を使用して、呼び出し元を認証します。IIS (Windows) 認証が使用できない異種環境では、IIS は匿名認証に対応するように構成されています。この場合、SOAP ヘッダーで渡されるチケットなどの、メッセージ レベルの属性を使用することによって、クライアントが認証されることがあります。

3. また、特定の IP アドレスを持つクライアント コンピュータからの要求のみを受理するように設定することも可能です。

4. IIS は、認証された呼び出し元の Windows アクセス トークンを ASP.NET に渡します。これは、Web サービスが匿名認証に対応するように構成されている場合は匿名インターネット ユーザーのアクセス トークンである場合があります。

5. ASP.NET が呼び出し元を認証します。Windows 認証に対応するように ASP.NET が設定されている場合、この時点ではこれ以外の認証は発生しません。IIS が呼び出し元を認証します。

   Windows 認証以外の方法を使用している場合は、カスタムの認証を使用できるようにするため、ASP.NET の認証モードは None に設定されています。

   メモ Web サービスでは、フォーム認証と Passport 認証は今のところサポートされていません。

6. ASP.NET は、URL 認定とファイル認定を使用して、要求された Web サービス (.asmx file) へのアクセスを認定します。URL 認定とファイル認定では、.asmx ファイルに関連付けられた NTFS アクセス権を使用して、認証された呼び出し元にアクセスを許可するかどうかが判断されます。

   メモ Windows認証では、ファイル認定だけがサポートされています。

   きめ細かい認定を行うため、.NET ロールを (宣言するか、またはプログラムで) 使用して、要求した Web メソッドへのアクセスを呼び出し元が認定されていることを確認することもできます。

7. Web サービス内のコードは、特定の ID を使用してローカルやリモートのリソースにアクセスすることがあります。既定では、ASP.NET Web サービスは偽装を行いません。その結果、構成された ASP.NET プロセス アカウントによって、その ID が提供されます。このほか、元の呼び出し元の ID や構成済みのサービスの ID などを使用することもできます。

ゲートキーパー

ASP.NET Web サービスの内部のゲートキーパーを以下に示します。

• IIS

  • IIS の匿名認証が無効になっている場合、IIS は認証されたユーザーからの要求のみを許可します。

  • IP アドレスの制限

    IIS は、特定の IP アドレスを持つコンピュータからの要求のみを許可するように構成することができます。

ASP.NET

• ファイル認定の HTTP モジュール (Windows 認証のみ)
• URL 認定の HTTP モジュール

プリンシパル アクセス許可要求および明示的なロール チェック

詳細情報

• ゲートキーパーの詳細については、「第 8 章 ASP.NET セキュリティ」の「ゲートキーパー」を参照してください。
• セキュリティの構成の詳細については、この章の後半の「セキュリティの構成」を参照してください。

認証および認定のしくみ

ここでは、一般的に使用される認証スキームに用意されている構成可能で、プログラムによる認定オプションを説明します。

ここでは、以下の認証スキーマの概要を説明します。

• 偽装を使用した Windows 認証
• 偽装を使用しない Windows 認証
• 固定 ID を使用した Windows 認証

偽装を使用した Windows 認証

以下の構成の要素は、Windows (IIS) 認証および偽装を Web.config または Machine.config で宣言して有効にする方法を示しています。

メモ 各 Web サービスの Web.config ファイルで、Web サービスごとに認証を構成する必要があります。

<authentication mode="Windows" />
<identity impersonate="true" />

この構成では、Web サービスのコードは IIS によって認証された呼び出し元を偽装します。最初の呼び出し元を偽装するには、IIS で匿名アクセスを無効にする必要があります。匿名アクセスでは、Web サービスのコードは匿名のインターネット ユーザー アカウントを偽装します。このアカウントは既定では IUSR_MACHINE です。

構成可能なセキュリティ

偽装と共に Windows 認証を使用するときは、以下の認定オプションを使用できます。

• Windows アクセス制御リスト (ACL)
  • Web サービス (.asmx) ファイル ファイル認定では、最初の呼び出し元のセキュリティ コンテキストを使用して、Web サービス ファイル .asmx などの要求された ASP.NET リソース のアクセス チェックが実行されます。最初の呼び出し元には、最低でも .asmx ファイルへの読み取りアクセスが許可されている必要があります。
  • Web サービスによってアクセスされるリソース Web サービスによってアクセスされるリソースには、ファイル、フォルダ、レジストリ キー、Active Directory? ディレクトリ サービス オブジェクトなどがありますが、これらの Windows ACL には、最初の呼び出し元に読み取りアクセスを許可する ACE (アクセス制御エントリ) が含まれている必要があります。これはリソースへのアクセスに使用される Web サービスのスレッドが呼び出し元を偽装しているためです。

URL 認定 これは Machine.config と Web.config の両方またはいずれかで構成されます。Windows 認証では、ユーザー名には DomainName\UserName という形式が使用され、ロールは Windows グループを使用して 1 対 1 でマップされます。

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

プログラムによるセキュリティ

プログラムによるセキュリティとは、Web サービスのコード内に配置されているセキュリティ チェックのことです。Windows 認証と偽装を使用するときは、プログラムによるセキュリティの以下のオプションを使用することができます。

• プリンシパル アクセス許可要求

  • 強制型 (メソッドのコード内でインラインで使用)

          PrincipalPermission permCheck = new PrincipalPermission(
                                            null, @"DomainName\WindowsGroup");
          permCheck.Demand();
    
    

  • 宣言型 (これらの属性は、Web メソッドまたは Web クラスの前に置くことが可能)

      // Demand that the caller is a member of a specific role (for Windows
      // authentication this is the same as a Windows group)
      [PrincipalPermission(SecurityAction.Demand, 
                        Role=@"DomainName\WindowsGroup")]
      // Demand that the caller is a specific user
      [PrincipalPermission(SecurityAction.Demand, 
                        Name=@"DomainName\UserName")]
    
    

明示的なロール チェック IPrincipal インターフェイスを使用して、ロール チェックを実行することができます。

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

どのような場合に使用するか

Windows 認証と偽装は、以下の場合に使用します。

• サーバーが認証することが可能な Windows アカウントを使用して、Web サービスのクライアントを特定することができる場合。
• 最初の呼び出し元のセキュリティ コンテキストを Web サービスを通じて次の層にフローする必要がある場合。たとえば、Enterprise Services (COM+) ロールを使用するサービス コンポーネント、またはきめ細かなユーザー単位の認定が必要なデータ層です。
• 最初の呼び出し元のセキュリティ コンテキストを下位層にフローして、オペレーティング システム レベルの監査をサポートする必要がある場合。

重要 偽装を使用すると、データベース接続プールに影響を及ぼすため、拡張性が低下することがあります。これ以外の方法として、Web サービスが呼び出し元を認定し、データベースへのアクセスに固定 ID を使用する、信頼されたサブシステム モデルを使用することを検討してください。たとえば、ストアド プロシージャのパラメータを使用して、呼び出し元の ID をアプリケーション レベルでフローすることができます。

詳細情報

• Windows 認証と偽装の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。
• URL 認定の詳細については、「第 8 章 ASP.NET セキュリティ」の「URL 認定の注意事項」を参照してください。

偽装を使用しない Windows 認証

以下の構成の要素は、偽装を使用しない Windows (IIS) 認証を Web.config で宣言して有効にする方法を示しています。

<authentication mode="Windows" />
<!-- The following setting is equivalent to having no identity element -->
<identity impersonate="false" />

構成可能なセキュリティ

偽装を利用しない Windows 認証を使用するときは、以下の認定オプションを使用できます。

• Windows ACL
  • Web サービス (.asmx) ファイル ファイル認定では、最初の呼び出し元を使用して、Web サービス ファイル .asmx を含む要求された ASP.NET リソースのアクセス チェックが実行されます。偽装は必要ありません。
  • アプリケーションによってアクセスされるリソース アプリケーションによってアクセスされるリソースにはファイル、フォルダ、レジストリ キー、Active Directory オブジェクトがありますが、これらの Windows ACL には、リソースへのアクセス時に Web サービス スレッドによって使用される既定の ID である ASP.NET プロセス ID に読み取りアクセスを許可する ACE が含まれていなければなりません。

URL 認定

これは Machine.config と Web.config 内で構成されます。Windows 認証では、ユーザー名には DomainName\UserName という形式が使用され、ロールは Windows グループを使用して 1 対 1 でマップされます。

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

プログラムによるセキュリティ

プログラムによるセキュリティとは、Web サービスのコード内に配置されているセキュリティ チェックのことです。偽装なしで Windows 認証を使用するときは、プログラムによるセキュリティの以下のオプションを使用することができます。

• プリンシパル アクセス許可要求

  • 強制型

        PrincipalPermission permCheck = new PrincipalPermission(
                                          null, @"DomainName\WindowsGroup");
        permCheck.Demand();
    
    

  • 宣言型

    // Demand that the caller is a member of a specific role (for Windows
    // authentication this is the same as a Windows group)
    [PrincipalPermission(SecurityAction.Demand, 
                      Role=@"DomainName\WindowsGroup")]
    // Demand that the caller is a specific user
    [PrincipalPermission(SecurityAction.Demand, 
                      Name=@"DomainName\UserName")]  
    
    
    

明示的なロール チェック IPrincipal インターフェイスを使用して、ロール チェックを実行することができます。

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

どのような場合に使用するか

偽装を利用しない Windows 認証は、以下の場合に使用します。

• サーバーが認証することが可能な Windows アカウントを使用して、Web サービスのクライアントを特定することができる。
• 接続プールをサポートするために、信頼されたサブシステム モデルを使用し、Web サービス内でクライアントを認証してから固定 ID を使用して下位のリソースにアクセスする必要がある。

詳細情報

• Windows 認証と偽装の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。
• URL 認定の詳細については、「第 8 章 ASP.NET セキュリティ」の「URL 認定の注意事項」を参照してください。

固定 ID を使用した Windows 認証

Web.config 内の <identity> 要素では、オプションのユーザー名およびパスワードをサポートしています。このため、Web サービスの特定の固定 ID を構成して、偽装することができます。こうする場合の構成ファイルの一部を以下に示します。

<identity impersonate="true" userName="DomainName\UserName" 
                             password="ClearTextPassword" />

どのような場合に使用するか

セキュリティで保護された環境では、この方法は以下の 2 つの理由によりお勧めできません。

• ユーザー名とパスワードは、構成ファイルにプレーン テキストで保存するべきではありません。
• Windows 2000 では、この方法を使用するには、"オペレーティング システムの一部として動作する" 特権を ASP.NET プロセス アカウントに許可しなければなりません。このため、Web サービスのセキュリティが低下し、悪意のあるユーザーによって Web サービスのプロセス (Aspnet_wp.exe) が悪用される危険性が増大します。

詳細情報

• Windows 認証と偽装の詳細については、「第 8 章 ASP.NET セキュリティ」を参照してください。
• URL 認定の詳細については、「第 8 章 ASP.NET セキュリティ」の「URL 認定の注意事項」を参照してください。

セキュリティの構成

ここでは、ASP.NET Web サービスのセキュリティを構成するために必要な実際の手順を説明します。これを要約したのが、図 10.4 です。

図 10.4 ASP.NET Web サービスのセキュリティを構成する

IIS の設定を構成する

IIS のセキュリティ設定を構成する方法の詳細については、「第 8 章 ASP.NET セキュリティ」の「セキュリティの構成」を参照してください。この情報は、ASP.NET Web サービスにも当てはまります。

ASP.NET の設定を構成する

アプリケーション レベルの構成の設定は、Web サービスの仮想ディレクトリに置かれている Web.config ファイルに保存されています。以下の設定を構成します。

1. 認証の構成 これは、Web サービスの仮想ルート ディレクトリに置かれている Web.config ファイル (Machine.config ではありません) で Web サービスごとに設定する必要があります。

   <authentication mode="Windows|None" />
   

   メモ Web サービスでは、Passport 認証およびフォーム認証は今のところサポートされていません。カスタムの認証およびメッセージ レベルの認証の場合は、モードを None に設定します。

2. 偽装および認定の構成 詳細については、「第 8 章 ASP.NET セキュリティ」の「セキュリティの構成」を参照してください。

詳細情報

URL 認定の詳細については、「第 8 章 ASP.NET セキュリティ」の「URL 認定の注意事項」を参照してください。

リソースをセキュリティで保護する

Web リソースをセキュリティで保護するには、「第 8 章 ASP.NET セキュリティ」に記載されているものと同じ方法を使用してください。ただし、Web サービスの場合、実際に稼動させるサーバーの Machine.config ファイルから HTTP-GET および HTTP-POST プロトコルを削除することも検討してください。

HTTP-GET および HTTP-POST を無効にする

既定では、クライアントが ASP.NET Web サービスとの通信に使用できるプロトコルは、HTTP-GET、HTTP-POST、および HTTP 上の SOAP の 3 つです。HTTP-GET と HTTP-POST のプロトコルを必要としない実稼動コンピュータでは、両方をマシン レベルで無効にする必要があります。この目的は、ファイアウォールの内側で実行されている内部の Web サービスが、有害な Web ページからアクセスされる原因となるセキュリティの抜け穴が発生するのを防ぐことです。

メモ これらのプロトコルを無効にすると、新しいクライアントは Web サービスのテスト ページの [起動] ボタンを使用して XML Web サービスをテストすることができなくなります。その代わりに、Microsoft Visual Studio? .NET の開発しシステムを使用して、Web サービスへの参照を追加し、テスト クライアント プログラムを作成する必要があります。場合によっては、これらのプログラムを開発用のコンピュータで有効にしておき、開発者がテスト ページを使用できるようにする必要があります。

■ コンピュータ全体の HTTP-GET および HTTP-POST プロトコルを無効にするには

1. Machine.config を編集します。

2. HTTP-GET および HTTP-POST のサポートを有効にしている、<webServices> 要素内の行をコメント アウトします。こうすると、Machine.config は以下のようになります。

   <webServices>
       <protocols>
         <add name="HttpSoap"/> 
           <!-- <add name="HttpPost"/> --> 
           <!-- <add name="HttpGet"/>  -->
         <add name="Documentation"/> 
       </protocols>
   </webServices>
   
   

3. Machine.config を保存します。

メモ HTTP-GET または HTTP-POST を使用して Web サービスと通信する Web サービス クライアントがあるような特別な場合は、これらのプロトコルのサポートをアプリケーションの Web.config ファイルに追加することができます。こうするには、前に説明したように、<webServices> を作成し、<protocol> 要素と <add> 要素を使用して、これらのプロトコルのサポートを追加します。

詳細情報

リソースのセキュリティ保護の詳細については、「第 8 章 ASP.NET セキュリティ」の「リソースをセキュリティで保護する」を参照してください。

通信のセキュリティ保護

通信リンクをセキュリティ保護するには、SSL と IPSec を組み合わせて使用します。

詳細情報

• SSL を使用して Web サービスを呼び出す方法の詳細については、このガイドの「パート IV : 参照」の「SSL を使用して Web サービスを呼び出す方法」を参照してください。
• 2 台のコンピュータ間で IPSec を使用する方法の詳細については、このガイドの「パート IV : 参照」の「2 つのサーバー間の通信を IPSec で保護する方法」を参照してください。

認証用の資格情報を Web サービスに渡す

Web サービスを呼び出すときは、ターゲットの Web サービスと同じメソッドのセットを公開するローカル オブジェクトである、Web サービスのプロキシを使用します。

Web サービスのプロキシは、コマンド ライン ユーティリティ Wsdl.exe を使用して生成します。または、Visual Studio .NET を使用している場合は、Web 参照をプロジェクトに追加してプロキシを生成することができます。

メモ プロキシを生成する必要がある Web サービスが、クライアント証明書を必要とするように構成されている場合は、参照を追加するか、エラーが発生している間、その要件が一時的に不要になるようにします。参照を追加したら、証明書が必要になるようにサービスを構成し直すことを忘れないでください。

これ以外の方法として、オフラインの WSDL (Web Services Description Language) ファイルをコンシューマ アプリケーションが使用できるようにしておくこともできます。Web サービスのインターフェイスを変更した場合は、このファイルを更新するのを忘れないでください。

Windows 認証で使用されるクライアントの資格情報の指定

Windows 認証を使用している場合は、Web サービス プロキシの Credentials プロパティを使用して、認証に使用される資格情報を指定する必要があります。このプロパティを明示的に設定しないと、資格情報を使用せずに Web サービスが呼び出されます。Windows 認証が必要な場合は、この結果、アクセスが拒否されたという応答である HTTP ステータス 401 が返されます。

DefaultCredentials の使用方法

クライアントの資格情報は、暗黙的にはフローされません。Web サービスの利用者は、資格情報と認証の詳細をプロキシで設定する必要があります。クライアントの Windows セキュリティ コンテキストの偽装しているスレッド トークンまたはプロセス トークンからのセキュリティ コンテキストを Web サービスにフローするには、以下に示すように、Web サービス プロキシの Credentials プロパティを CredentialCache.DefaultCredentials に設定します。

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

この方法を使用する前に、以下の点を考慮してください。

この方法では、NTLM 認証、Kerberos 認証、またはネゴシエート認証を使用しているときはクライアントの資格情報のみがフローされます。

Windows フォーム アプリケーションなどのクライアント側のアプリケーションが Web サービスを呼び出した場合、資格情報はユーザーの対話型のログオン セッションから取得されます。

ASP.NET Web アプリケーションなどの、クライアント側のアプリケーションは、偽装が構成されている場合を除き、プロセス ID を使用します。偽装が構成されている場合は、偽装された呼び出し元の ID が使用されます。

特定の資格情報の使用方法

Web サービスを呼び出すときに、特定の資格情報のセットを認証に使用するには、以下のコードを使用します。

CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web service URL
           "Negotiate",        // Kerberos or NTLM
           new NetworkCredential("username", "password", "domainname") );
proxy.Credentials = cache;

上記の例では、要求されるネゴシエート認証のタイプは、Kerberos 認証、NTLM 認証のいずれかになります。

常に特定のタイプの認証を要求する

上記のように、常に特定のタイプの認証を要求する必要があります。NetworkCredential クラスは、以下のコードに示すように直接使用しないでください。

proxy.Credentials = new 
                      NetworkCredential("username", "password", "domainname");

これは、実動させるコードでは使用するべきではありません。この理由は、Web サービスによって使用される認証機構を管理することは不可能であり、その結果、資格情報が使用される方法を管理することも不可能であるためです。

たとえば、Kerberos や NTLM の認証要求がサーバーから送られてくることを期待しても、基本認証要求を受け取ることがあります。この場合、渡されたユーザー名とパスワードは、クリア テキスト形式でサーバーに送信されます。

PreAuthenticate プロパティを設定する

プロキシの PreAuthenticate プロパティは、true または false に設定することができます。これを true に設定すると、特定の認証資格情報が渡されるため、HTTP ヘッダー WWW-authenticate が Web 要求と共に渡されます。これによって、Web サーバーが要求に関してアクセスを拒否し、その後の再試行要求で認証を実行する処理が省かれます。

メモ 事前認証は、最初の Web サービスの認証が正常に行われた後でのみ適用されます。事前認証は、最初の Web 要求には影響しません。

private void ConfigureProxy( WebClientProtocol proxy, 
                             string domain, string username, 
                             string password )
{
  // To improve performance, force pre-authentication
  proxy.PreAuthenticate = true;
  // Set the credentials
  CredentialCache cache = new CredentialCache();
  cache.Add( new Uri(proxy.Url),
             "Negotiate",     
             new NetworkCredential(username, password, domain) );
  proxy.Credentials = cache;
  proxy.ConnectionGroupName = username;
}

ConnectionGroupName プロパティの使用方法

上のコードでは、Web サービス プロキシの ConnectionGroupName プロパティが設定されています。これが必要になるのは、以下に説明するように、Web サービスへの接続に使用されるセキュリティ コンテキストが要求ごとに異なる場合です。

上に示すように、DefaultCredentials を使用するか、明示的な資格情報を設定することによって、Web サービスに接続し、最初の呼び出し元のセキュリティ コンテキストをフローする ASP.NET Web アプリケーションがある場合は、Web サービス プロキシの ConnectionGroupName プロパティを Web アプリケーション内部で設定しなければなりません。この目的は、前のクライアントの認証資格情報に関連付けられている Web サービスへの認証済みの古い TCP 接続を、新しい未認証のクライアントが再使用できないようにすることです。接続の再使用は、HTTP KeepAlives と、パフォーマンスの理由により IIS で有効にされる認証の継続性の結果として発生します。

上のコードに示すように、ConnectionGroupName プロパティを、呼び出し元ごとに区別される識別子、例えば、呼び出し元のユーザー名などに設定します。

メモ 最初の呼び出し元のセキュリティ コンテキストは Web アプリケーションを通じて Web サービスにフローされないが、Web アプリケーションがWeb アプリケーションの ASP.NET プロセス ID などの固定 ID を使用して Web サービスに接続する場合、ConnectionGroupName を設定する必要はありません。この場合は、接続のセキュリティ コンテキストが呼び出し元ごとに変わることはありません。

Windows 以外のクライアントからのWeb サービスの呼び出し

異種のブラウザ間で機能する認証方法が多数あります。これには、次のようなものがあります。

• 証明書認証 クロス プラットフォームの X.509 証明書を使用します。
• 基本認証 Active Directory を使用せずに基本認証をカスタムのデータ ストアに対して使用する方法の例については、「Web Services Security - HTTP Basic Authentication without Active Directory」 (英語情報) を参照してください。
• GXA のメッセージ レベルの認証方法 Web Services Development Toolkit を使用して GXA (WS-Security) ソリューションを実装します。
• カスタムの認証方法 たとえば、資格情報を SOAP ヘッダーでフローします。

プロキシ サーバーの認証

プロキシ サーバーの認証は、Visual Studio .NET の [Web 参照の追加] ダイアログ ボックスではサポートされていません。ただし、次のバージョンの Visual Studio .NET でサポートされる予定です。その結果、Web 参照を追加したときに、"プロキシへの認証が必要です" という応答である HTTP ステータス 407 を受け取ることがあります。

メモ ブラウザで .asmx ファイルを表示しているときは、ブラウザが自動的に資格情報を送信するため、このエラーが表示されないことがあります。

この問題を回避するには、以下に示すように、コマンド ライン ユーティリティ Wsdl.exe を使用します。[Web 参照の追加] ダイアログ ボックスは使用しません。

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword> /pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

プロキシ サーバーの認証情報をプログラムで設定する必要がある場合は、以下のコードを使用します。

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

最初の呼び出し元のフロー

ここでは、ASP.NET Web アプリケーションを通じて、最初の呼び出し元のセキュリティ コンテキストをリモートのアプリケーション サーバーにある Web サービスにフローする方法を説明します。こうする必要があるのは、Web サービスまたはデータベースなどの下位のサブシステムの内部で、ユーザー単位の認証をサポートする場合です。データベースでは、個々のデータベース オブジェクトに対して最初の呼び出し元を認定する必要があります。

図 10.5 では、最初の呼び出し元 (Alice) のセキュリティ コンテキストは、ASP.NET Web アプリケーションをホストするフロントエンドの Web サーバーを通じて、リモートのアプリケーション サーバーの ASP.NET によってホストされるリモート オブジェクトにフローされ、最終的にバックエンドのデータベース サーバーに達します。

図 10.5 最初の呼び出し元のセキュリティ コンテキストをフローする

資格情報を Web サービスにフローするため、Web サービスのクライアント (この場合は ASP.NET Web アプリケーション) では、Web サービス プロキシを構成し、プロキシの Credentials プロパティを明示的に設定する必要があります。これについては、この章の前半の「認証用の資格情報を Web サービスに渡す」で説明されています。

呼び出し元のコンテキストをフローする方法は、以下の 2 つです。

• 既定の資格情報を渡し、Kerberos 認証 (および委任) を使用する。 この方法では、ASP.NET Web アプリケーション内で偽装を行い、偽装された呼び出し元のセキュリティ コンテキストから取得した DefaultCredentials でリモート オブジェクトのプロキシを構成する必要があります。
• 明示的な資格情報を渡し、基本認証またはフォーム認証を使用する。 この方法では、ASP.NET Web アプリケーション内で偽装を行う必要はありません。その代わりに、Web アプリケーションが使用することが可能な、サーバー変数 (基本認証の場合) またはHTML フォーム フィールド (フォーム認証の場合) から取得した明示的な資格情報を使用して、プログラムで Web サービス プロキシを構成します。基本認証またはフォーム認証では、サーバーはクリア テキストのユーザー名とパスワードを使用できます。

既定の資格情報に Kerberos の委任を使用する

Kerberos の委任を使用するには、サーバーとクライアントのすべてのコンピュータで Windows 2000 以上が実行されている必要があります。さらに、委任されるクライアントのアカウントは Active Directory に格納されている必要がありますが、"アカウントは重要なので委任できない" とマークされていてはなりません。

次の表は、Web サーバーおよびアプリケーション サーバーに必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

リモートのアプリケーション サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

詳細情報

Kerberos の委任を構成する方法の詳細については、このガイドの「パート IV : 参照」の「Windows 2000 での Kerberos 委任の構成方法」を参照してください。

明示的な資格情報に基本認証またはフォーム認証を使用する

Kerberos の委任を使用する代わりに、Web アプリケーションで基本認証またはフォーム認証を使用してクライアントの資格情報を取得し、Web サービスに基本認証、または Windows 統合認証を使用することができます。

この方法では、Web アプリケーションはクライアントのクリア テキストの資格情報を使用できます。資格情報は、Web サービス プロキシを通じて Web サービスに渡すことが可能です。この場合、クライアントの資格情報を取り出すように Web アプリケーションのコードを記述し、プロキシを構成する必要があります。

基本認証

基本認証では、Web アプリケーションは最初の呼び出し元の資格情報をサーバー変数内で使用できます。以下のコードは、資格情報を取得し、Web サーバー プロキシを構成する方法を示しています。

// Retrieve client's credentials (available with Basic authentication)
string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

フォーム認証

フォーム認証では、Web アプリケーションは最初の呼び出し元の資格情報をサーバー変数ではなくフォーム フィールド内で使用できます。この場合は、以下のコードを使用します。

// Retrieve client's credentials from the logon form
string pwd = txtPassword.Text;
string uid = txtUid.Text;
// Associate the credentials with the Web service proxy
// To improve performance, force preauthentication
proxy.PreAuthenticate = true;
// Set the credentials
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url),
           "Basic",     
           new NetworkCredential(uid, pwd, domain) );
proxy.Credentials = cache;

次の表は、Web サーバーおよびアプリケーション サーバーに必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows" />

<authentication mode="Forms" />

<identity impersonate="false" />

アプリケーション サーバーの構成

<authentication mode="Windows" />

<identity impersonate="true" />

信頼されたサブシステム

信頼されたサブシステム モデルは、最初の呼び出し元のセキュリティ コンテキストをフローする別の実装がより簡単な方法として使用できます。このモデルには、Web サービスと Web アプリケーションの間に信頼の境界が存在します。要求を Web サービスに移す前に、Web サービスは Web アプリケーションを信頼して、呼び出し元を正しく認証および認定します。最初の呼び出し元の認証は、Web サービスでは発生しません。Web サービスは、Web アプリケーションによって使用される、信頼された固定 ID を認証して、Web サービスと通信します。ほとんどの場合、これは ASP.NET ワーカー プロセスのプロセス ID です。

図10.6 に、信頼されたサブシステム モデルを示します。

図 10.6 信頼されたサブシステム モデル

呼び出し元の ID をフローする

信頼されたサブシステム モデルを使用する場合は、データベースで監査するなどの目的で、最初の呼び出し元の ID (セキュリティ コンテキストではなく、名前) をフローしなければならないことがあります。

ID は、メソッドおよびストアド プロシージャのパラメータを使用して、アプリケーション レベルでフローすることができます。また、信頼されたクエリ パラメータを使用して、ユーザー固有のデータをデータベースから取り出すことが可能です。

SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"

構成手順

次の表は、Web サーバーおよびアプリケーション サーバーに必要な構成の手順を示しています。

Web サーバーの構成

<authentication mode="Windows|Forms|Passport" />

<identity impersonate="false" />

proxy.Credentials = DefaultCredentials;

アプリケーション サーバーの構成

<authentication mode="Windows" />