リダイレクトを知っているときにHttpWebRequest.CredentialsのCredentialCacheを構築する

Question

最近、サーバーがリダイレクトを返すときに、NetworkCredentialとHttpWebRequest.Credentialsに関してquestionが尋ねられました。自分のシナリオでNetworkCredentialインスタンスのCredentialCacheを構築することができると判断しました。今私はすべてのドメイン名がハードコードされたCredentialCacheを構築する一時的な方法を持っています。それはうまくいきました。

 CredentialCache cache = new CredentialCache(); 
     cache.Add(new Uri("http://example.com"), "Negotiate", loginCredentials); 
     cache.Add(new Uri("http://redirected.example.com"), "Negotiate", loginCredentials); 
     request.Credentials = cache; 

これをもっと柔軟にする必要があります。リダイレクトのアイデア全体は、サーバー上の負荷分散のためのものです。クライアントは、HttpWebRequest.GetResponse（）の呼び出しまでリダイレクト先を正確に知ることはできません。それぞれのリダイレクトされたサーバーに遭遇したときにそれらを含めるためにCredentialCacheを構築するための好ましい方法は何ですか？また、これを難しくする背後にある合理的なものは何ですか？ 1つのNetworkCredentialsインスタンスが各リダイレクトに対してHttpWebRequest.Credentialsを満たしていないのはなぜですか？リダイレクトを介して資格情報を再利用するためのセキュリティ上の脆弱性が導入されていますか？

ありがとうございました。

Answer 1

ネイト、

私は、あなたが "交渉" を使用している参照して、なぜあなたはすべてのリダイレクトのための

CredentialCache.DefaultNetworkCredentials or CredentialCache.DefaultCredentials 

を使用していませんか？ MSDNから

： DefaultNetworkCredentialsプロパティによって返さ

資格情報は のみNTLMに適用され、交渉、 とKerberosベースの認証。 DefaultNetworkCredentialsによって返さ

資格情報は アプリケーションが実行されている 現在のセキュリティコンテキストの 認証資格情報を表します。 クライアント側アプリケーションの場合、通常、アプリケーションを実行する ユーザーのWindows資格情報（ユーザー の名前、パスワード、およびドメイン）は です。 ASP.NETアプリケーションの場合、デフォルトの ネットワーク資格情報は、ログインしたユーザーのユーザー 資格情報またはユーザーが偽装された です。

Answer 2

コードを使用して401エラー（SharePoint 2010 OOB Web Services）が発生しました。その後、他のサイトでチェックし、以下の行に "Negotiate"の代わりに "NTLM"を試してみました。今はうまくいきます。

は動作しない：

cache.Add(New Uri(myProxy.Url), "Negotiate", New NetworkCredential("UserName", "Password", "Domain")) 

ワーキング：

cache.Add(New Uri(myProxy.Url), "NTLM", New NetworkCredential("UserName", "Password", "Domain"))