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