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