HTTP 認証の理解
認証は、リソースにアクセスする権限をクライアントが持つかどうかを確認するプロセスです。HTTP プロトコルは、セキュリティで保護されたリソースへのアクセスをネゴシエートする手段として、認証をサポートしています。
クライアントからの最初の要求は、通常、認証情報を含まない匿名要求です。HTTP サーバー アプリケーションは、認証が必要であることを示して匿名要求を拒否できます。その場合は、サポートされる認証方式を示す WWW 認証ヘッダーを送信します。ここでは、複数の HTTP 認証方式を示し、Windows Communication Foundation (WCF) での各 HTTP 認証方式のサポートについて説明します。
HTTP 認証方式
サーバーは、クライアントが選択できる複数の認証方式を指定できます。Windows アプリケーションで一般的に使用される認証方式のいくつかを次の表に示します。
| 認証方式 | 説明 |
|---|---|
匿名 |
匿名要求は、認証情報を含みません。これは、リソースへのアクセス権をすべてのユーザーに付与することを意味します。 |
基本 |
基本認証では、クライアントのユーザー名とパスワードを含む Base64 エンコード文字列が送信されます。Base64 は暗号化の形式ではありません。クリア テキストでのユーザー名とパスワードの送信と同じであると考えてください。リソースを保護する必要がある場合は、基本認証以外の認証方式の使用を検討してください。 |
ダイジェスト |
ダイジェスト認証は、基本認証の代わりに使用できるチャレンジ レスポンス方式の認証です。サーバーは、nonce と呼ばれるランダムな文字列データをチャレンジとしてクライアントに送信します。クライアントは、ユーザー名、パスワード、nonce およびその他の追加情報を含むハッシュを使用して応答します。この認証方式では、このようなデータの交換によってもたらされる複雑さとデータのハッシュにより、ユーザーの資格情報を盗んで再使用することがより困難になります。 ダイジェスト認証では、Windows ドメイン アカウントを使用する必要があります。ダイジェストのレルムは Windows ドメイン名です。したがって、Windows ドメインをサポートしていないオペレーティング システム (Windows XP Home Edition など) で実行されているサーバーでは、ダイジェスト認証を使用できません。逆に、Windows ドメインをサポートしていないオペレーティング システムでクライアントが実行されている場合は、認証時にドメイン アカウントを明示的に指定する必要があります。 |
NTLM |
NTLM (NT LAN Manager) 認証もチャレンジ レスポンス方式の認証ですが、ダイジェスト認証よりもセキュリティが強化されています。NTLM 認証では、エンコードされていないユーザー名とパスワードではなく、Windows 資格情報を使用してチャレンジ データが変換されます。NTLM 認証では、クライアントとサーバー間で複数のメッセージ交換を行う必要があります。認証を正常に完了するため、サーバーおよび介在するすべてのプロキシが永続的な接続をサポートしている必要があります。 |
Negotiate |
ネゴシエート認証では、可用性に応じて、Kerberos プロトコルと NTLM 認証のいずれかが自動的に選択されます。Kerberos プロトコルを使用できる場合は Kerberos プロトコルが使用され、それ以外の場合は NTLM が使用されます。Kerberos 認証は、NTLM 認証を大幅に強化した認証方式です。Kerberos 認証は NTLM 認証よりも高速であるだけでなく、相互認証およびリモート コンピュータへの資格情報の委任を使用できます。 |
Passport |
基になる Windows HTTP サービスには、フェデレーション プロトコルを使用する認証が含まれます。ただし、WCF の標準 HTTP トランスポートは、Microsoft Passport などのフェデレーション認証方式をサポートしていません。現時点では、この機能をサポートするには、メッセージ セキュリティを使用する必要があります。詳細な情報については、次のページを参照してください。 「フェデレーションと発行済みトークン」を参照してください。 |
認証方式の選択
HTTP サーバーに使用できる認証方式を選択する際には、以下の項目について検討します。
- リソースを保護する必要があるかどうかを検討します。HTTP 認証では、より多くのデータを送信する必要があるため、クライアントとの相互運用性が制限される可能性があります。保護する必要のないリソースには、匿名アクセスを許可してください。
- リソースを保護する必要がある場合は、必要なレベルのセキュリティがどの認証方式によって提供されるかを検討します。ここで説明した中で最も弱い標準の認証方式は、基本認証です。基本認証では、ユーザーの資格情報が保護されません。最も強力な標準の認証方式は、ネゴシエート認証で選択される Kerberos プロトコルです。
- 受け入れる準備ができていない認証方式、またはリソースを十分にセキュリティで保護できない認証方式をサーバーが (WWW 認証ヘッダー内で) 提示しないことを確認してください。クライアントは、サーバーによって提示された認証方式を自由に選択します。クライアントによっては、弱い認証方式、またはサーバーのリストにある最初の認証方式を既定で選択します。