ASP.NET を使用して作成した XML Web サービスのセキュリティ

[アーティクル]
02/24/2011

このトピックの対象は、レガシテクノロジに特定されています。XML Web サービスと XML Web サービスクライアントは以下を使用して作成してください。 Windows Communication Foundation.

Web サービスに最適なセキュリティ実装を決定するときは、まず認証と承認という 2 つの重要なセキュリティ原則について決定します。認証とは、ユーザー名やパスワードなど、資格情報に基づく ID を証明機関に照会して検証するプロセスです。ID が認証されると、承認によって、その ID がリソースへのアクセスを与えるかどうかが決定されます。

ASP.NET を使用して作成した Web サービスでは、ASP.NET で用意されている認証オプションおよび承認オプションや、カスタマイズされた SOAP ベースのセキュリティからセキュリティオプションを選択できます。ASP.NET ではインターネットインフォメーションサービス (IIS: Internet Information Services) と連動して、さまざまな認証オプションと承認オプションを使用できます。SOAP ヘッダーを使用するなど、カスタム認証オプションも作成できます。また、ASP.NET には、偽装と呼ばれる機能が用意されています。偽装は、クライアント資格情報を使用して要求を実行する機能です。偽装の使用の詳細については、「ASP.NET の偽装」を参照してください。

このトピックでは、ASP.NET を使用して構築した Web サービスで使用できる認証オプションと承認オプションの概要について説明します。ASP.NET Web アプリケーションで使用できるセキュリティオプションの詳細については、「ASP.NET Web アプリケーションのセキュリティ」と、「セキュリティ保護された ASP.NET アプリケーションの構築: 認証、認定、およびセキュリティで保護された通信」を参照してください。

ASP.NET ベースアプリケーションからのリモートリソースへのアクセスの詳細については、「セキュリティ保護された ASP.NET アプリケーションの構築」の第 3 章の「偽装および委任モデル」と「信頼されたサブシステムモデル」の各項目を参照してください。

XML Web サービスの認証オプション

ASP.NET を使用して作成した Web サービスには、クライアント認証用のオプションが複数あるため、特定の Web サービスに対して適切なオプションを選択することが重要です。適切なセキュリティオプションを選択するときに、二者択一を迫られるものとして、セキュリティとパフォーマンスのレベルがあります。一部の Web サービスでは、クライアント資格情報を暗号化してネットワーク経由で送信する必要があるため、クライアント資格情報を暗号化するアルゴリズムが必要です。たとえば、クレジットカードを処理する Web サービスを作成する場合、開発者は、クレジットカードデータの暗号化による追加のオーバーヘッドが発生することよりも、クライアント資格情報がネットワークで盗用されることを懸念します。

次の表に、ASP.NET を使用して作成した Web サービスで使用できる認証オプションの概要を示します。先頭に Windows が付けられたオプションは、ASP.NET を使用して作成した Web サービスで使用できる Microsoft Windows 認証オプションです。

認証オプションの概要

認証オプション	説明
Windows - 基本	クライアントの ID をセキュリティ保護しない場合に使用します。ユーザー名とパスワードは Base 64 エンコード文字列としてプレーンテキストで送信されます。この認証オプションでは、パスワードとユーザー名はエンコードされますが、暗号化されません。悪意のあるユーザーがネットワーク監視ツールを使用すれば、ユーザー名とパスワードを傍受できます。
Windows - 基本 (SSL)	インターネットを利用するシナリオで、クライアントの ID をセキュリティ保護する場合に使用します。ユーザー名とパスワードは、プレーンテキストではなく、SSL (Secure Sockets Layer) で暗号化してネットワーク経由で送信されます。この方法は構成が比較的簡単で、インターネットを使用する場合に有効です。ただし、SSL を使用するとパフォーマンスが低下します。
Windows - ダイジェスト	インターネットを利用するシナリオで、クライアントの ID をセキュリティ保護する場合に使用します。ハッシュを使用してクライアント資格情報を暗号化して送信するため、パスワードはクリアテキストで送信されません。また、ダイジェスト認証ではプロキシサーバーを利用できます。ただし、他のプラットフォームでもダイジェスト認証が広く採用されているわけではありません。
Windows - 統合 Windows	NTLM または Kerberos を使用します。ユーザーの Microsoft Internet Explorer (Web ブラウザー) を使用し、データを暗号化して通信します。
Windows - クライアント証明書	インターネットとイントラネットを利用するシナリオで、クライアントの ID をセキュリティ保護する場合に使用します。各クライアントは、相互信頼を確立した証明機関から証明書を取得する必要があります。オプションとして、証明書をユーザーアカウントにマップすることもできます。証明書は、IIS で Web サービスへのアクセスを承認するときに使用されます。
フォーム	Web サービスではサポートされません。これは、HTTP クライアント側リダイレクトを使用して、未認証の要求を HTML フォームにリダイレクトするシステムです。Web サービスの大半のクライアントは、UI を使用した資格情報の提供を行いません。フォーム認証を使用する場合は、この点に対処する必要があります。
SOAP ヘッダー – カスタム	インターネットを利用するシナリオで、ID をセキュリティ保護する場合と保護しない場合の両方で使用できます。ユーザー資格情報は、SOAP メッセージの SOAP ヘッダーに格納されて渡されます。Web サーバーは、Web サービスをホストするプラットフォームに関係なく、カスタム認証の実装をサポートします。

SOAP ヘッダーを除いて、上記のすべてのオプションについては、構成ファイルと IIS を組み合わせることによって、セキュリティ設定を指定します。カスタム SOAP ヘッダーオプションについては、認証と承認の両方が必要であるため、後の承認に関するセクションで詳しく説明します。

Windows 認証

IIS と ASP.NET は、Windows に組み込みのセキュリティ機能を使用した、Web サービスなどの Web アプリケーションの認証をサポートします。Windows には、基本認証、ダイジェスト認証、統合 Windows 認証という 3 つの認証オプションがあります。また、各オプションでは SSL を使用できます。基本認証以外の Windows 認証では、何らかの形式でデータを暗号化するため、一般に、SSL による追加の暗号化レベルを使用するのは、基本認証またはクライアント証明書認証と組み合わせて使用する場合に限られます。

使用する Windows 認証オプションの種類に関係なく、Web サービスと Web サービスクライアントを設定する手順は似ています。詳細については、「方法 : Windows 認証用に XML Web サービスを構成する」を参照してください。認証オプションは構成ファイルと IIS で設定されるので、Windows 認証を使用するために Web サービスにコードを追加する必要はありません。Web サービスクライアントには、Web サービスにクライアント資格情報を渡すためのコードを追加する必要があります。

Web サービスで使用する認証機構の一部として SSL を組み込む場合は、IIS を使用して、Web サービスをホストする Web アプリケーションまたは Web サービス自体に対して SSL を構成する必要があります。SSL を使用してサービスの説明とサービスヘルプページにアクセスする場合、サービスの説明と、サービスの説明から生成されるプロキシクラスには、Web サービスでの SSL の使用が反映されます。サービスの説明内にある Web サービスの URL の先頭には、https が付けられます。SSL の設定の詳細については、IIS のドキュメントを参照してください。

クライアント証明書認証

クライアント証明書を使用すると、安全な認証を行えます。クライアントは、クライアント証明書と呼ばれる電子ドキュメントを送信するように要求され、Web サーバーとの SSL 接続を使用してクライアントが識別されます。SSL 接続では、クライアント証明書をネットワーク経由で送信するときに、クライアント証明書内に格納されるクライアント資格情報を暗号化します。クライアントと Web サーバー間の通信は、クライアントが送信する暗号化キーと、Web サーバーが用意するキーを組み合わせて暗号化されます。通信が確立されたら、そのクライアントコンピューターとサーバーコンピューターだけが、その SSL 接続を使用して相互に通信できます。

クライアント証明書は、Web サーバー自体か、クライアントとサーバー間にある信頼できる機関のいずれかの証明機関から取得できます。クライアント証明書の取得と、証明書を受け入れるための Web サーバーの構成が完了すれば、Web サービスが呼び出されたときに、クライアントは SSL 接続を使用して Web サーバーにクライアント証明書を送信できます。クライアント証明書の詳細については、IIS のドキュメントを参照してください。Web サービス用にクライアント証明書認証を設定する方法の詳細については、「方法 : Windows 認証用に XML Web サービスを構成する」を参照してください。

XML Web サービスの承認オプション

承認の目的は、ある ID に対して、特定リソースへの要求された種類のアクセス権を与えるかどうかを判断することです。特定のリソースへのアクセス権を承認する方法には、ファイル承認と URL 承認という 2 種類の基本となる方法があります。IIS ではファイル単位でアクセス許可が設定されるため、ファイル承認は Windows 認証が使用されていれば使用できます。URL 承認は、ASP.NET がサポートする組み込みの認証機構であればどれでも組み合わせて使用できます。URL 承認の構成は、構成ファイルで行います。構成ファイルを使用して、.asmx ファイルなど、ASP.NET に関連付けられたファイルへのアクセス権をユーザーに対して個別に許可したり、拒否したりできます。

ファイル単位での承認の設定については、IIS のドキュメントを参照してください。

構成ファイルを使用した承認の設定の詳細については、「ASP.NET の承認」を参照してください。

SOAP ヘッダーを使用したカスタム認証

クライアント証明書などの Windows 認証機構は HTTP トランスポートに依存しますが、SOAP はトランスポートに依存しません。ASP.NET を使用して作成した Web サービスでは、SOAP over HTTP の他に、非 SOAP XML ドキュメントを返す HTTP-POST および HTTP-GET の実装も使用します。そのため、カスタム認証機構を作成する理由の 1 つとしては、トランスポートから認証を切り離すことが挙げられます。これを行うには、SOAP ヘッダーで認証資格情報を渡します。

SOAP ヘッダーは、帯域外情報、つまり Web サービスのセマンティクスに関係のない情報を渡すときに有用な方法です。SOAP メッセージの Body 要素には Web サービス操作用の in パラメーターと out パラメーターが含まれ、Web サービスメソッドで処理されますが、それとは異なり、Header 要素は省略可能で、インフラストラクチャで処理できます。つまり、カスタム認証機構が用意されたインフラストラクチャで処理できます。

認証に SOAP ヘッダーを使用する方法については、「方法 : SOAP ヘッダーを使用してカスタム認証を実行する」を参照してください。

認証に SOAP ヘッダーを使用する場合、Web サービスクライアントは必要な SOAP ヘッダーを SOAP 要求に追加し、そこにクライアント資格情報を格納して、クライアント資格情報を Web サービスに送信します。SOAP ヘッダー認証を使用する場合、Web サービスでは、認証資格情報が格納された SOAP ヘッダーが必要であることを指定し、クライアントに対して Web サービスへのアクセス権を承認する必要があります。

参照

次の方法で共有