次の方法で共有


HttpChannel による Web セキュリティ

Web セキュリティは、暗号化された通信や認証のためのインターネット標準に基づいています。HttpChannel クラスは、送信側ではマネージ ネットワークを使用し、受信側ではインターネット インフォメーション サービス (IIS: Internet Information Services) と ASP.NET のセキュリティ機能を組み合わせて使用し、Web セキュリティを提供しています。資格情報 (UsernamePassword、およびオプションの Domain) は、HttpChannel のプロパティで設定できます。資格情報はリモート処理インフラストラクチャによって System.Net に渡され、System .Net からサーバーに渡されます。チャネル メッセージ シンクのプロパティには、既定で資格情報を最初のメッセージと共に送信する PreAuthenticate プロパティが含まれています。

認証

ASP.NET で管理されるアプリケーションは、IIS と ASP.NET のセキュリティ機能を組み合わせて認証を行うように設定できます。ASP.NET アプリケーション仮想ディレクトリは、IIS および ASP.NET のセキュリティ機能を使用するように設定されています。IIS および ASP.NET での認証設定の詳細については、IIS のドキュメントおよび「ASP.NET Web アプリケーションのセキュリティ」を参照してください。

ASP.NET での安全な通信

ASP.NET と組み合わされた IIS で管理される HttpChannel は、SSL (Secure Sockets Layer) による、暗号化された通信の送受信をサポートします。SSL の設定については、IIS のドキュメントを参照してください。https というテキストと適切な URL を、Activator.CreateInstanceActivator.GetObject の呼び出しの先頭、.NET リモート処理構成ファイル内、または URL でリモート オブジェクト、リモートの XML Web サービス、およびリモート処理アプリケーションを指定している場所に挿入します。

HTTP 接続が暗号化されているかどうかを調べるには、HttpContext.Request プロパティを呼び出して HttpRequest オブジェクトを取得し、HttpRequest.IsSecureConnection を呼び出します。

Anonymous

ユーザーが匿名での接続を確立できるようにするには、このオプションを使用します。ユーザーは匿名またはゲスト アカウントでサーバーにログオンできるようになります。

**メモ   **基本認証、ダイジェスト認証、または統合 Windows 認証を使用する場合は、匿名をオフにしておく必要があります。

基本認証

基本認証は、標準の HTTP 機構を使用したセキュリティ機構で、ユーザー情報はビットストリーム化されたバイナリ情報ではなく、プレーンなテキスト文字で送受信されます。基本認証では、Base 64 でエンコードされた、ユーザー名とパスワードを含む文字列が使用されます。この種類の認証では、パスワードとユーザー名はエンコードされますが、暗号化されません。基本認証を使用すると、パスワードが暗号化されないままネットワーク上を伝送されるので注意が必要です。つまり、ネットワーク監視ツールを備えたコンピュータを持つ未認証のユーザーにより、ユーザー名とパスワードが傍受される可能性があります。

基本認証は、アプリケーションが呼び出し元のアプリケーションのためになんらかの ID を必要とする場合に便利です。

ダイジェスト認証

ダイジェスト認証はネットワークに、パスワードではなくハッシュ値を送出します。この方法は、プロキシ サーバーやその他のファイアウォールを越えて動作します。

ダイジェスト認証は、1 回だけの値 (サーバーが指定したデータ文字列値) を使用してユーザー情報を認証チャレンジ応答するスキームです。有効な応答にはユーザー名、パスワード、与えられた 1 回だけの値、HTTP メソッド、および要求された URI (Uniform Resource Identifier) のチェックサムが含まれています。

ダイジェスト認証では、基本認証の弱点の多くが解決されています。最も重要な点は、ダイジェスト認証を使用すると、パスワードがクリア テキストでは伝送されないことです。ダイジェスト認証は統合 Windows 認証と異なり、プロキシ サーバーを通じて動作することもできます。

ダイジェスト認証は、アプリケーションが基本認証よりも強力な認証を必要とする場合に役立ちます。

一般に、Cookie 認証とは、認証されていない要求を HTTP クライアント側リダイレクトを使用して HTML フォームにリダイレクトするシステムのことを指します。ユーザーが資格情報を入力し、フォームを送信します。アプリケーションが要求を認証すると、このシステムはなんらかの形式の資格情報が含まれた Cookie または ID を再取得するためのキーを発行します。それ以降の要求は、要求ヘッダー内の Cookie を使用して発行され、アプリケーションが要求する検証方法で ASP.NET ハンドラによって認証および許可されます。

Cookie 認証は、コンテンツを既知のユーザー用にカスタマイズするパーソナル化の目的で使用されることが少なくありません。このような場合には認証よりも識別が重視されるため、長期間維持しておくことのできる Cookie にユーザー名を格納し、その名前を利用してユーザーのパーソナル化情報にアクセスできるようにしておくだけで十分です。

統合 Windows 認証

統合 Windows 認証を使用すると、ユーザーの Microsoft Internet Explorer との間で暗号化したデータを交換できます。

統合 Windows 認証は、NT LAN Manager (または NTLM) および Windows NT チャレンジ/応答認証として以前から知られている認証で、基本認証よりも高い安全性を備えています。この認証方式は、ユーザーが Windows ドメインのアカウントを持っているイントラネット環境で特に役立ちます。

統合 Windows 認証では、ブラウザはドメインへのログオン時から、現在のユーザーの資格情報を使用します。この資格情報が拒否されると、統合 Windows 認証はユーザーに対して、ユーザー名とパスワードを入力するダイアログ ボックスを表示します。統合 Windows 認証を使用した場合、ユーザーのパスワードはクライアントからサーバーに渡されません。ユーザーがローカルのコンピュータにドメイン ユーザーとしてログオンした場合は、そのドメイン内のネットワーク コンピュータにアクセスするときに再び認証される必要はありません。

HTTP 要求が発行されるたびにユーザーに対してユーザー名とパスワードの入力が要求されることはありません。ダイアログ ボックスは、キャッシュされていた資格情報が特定のページやファイルにアクセスするための十分なアクセス許可を持っていない場合にだけ表示されます。

参照

セキュリティ | マネージ アプリケーションでのロール ベース セキュリティ