ADFS v2.0 エラー:MSIS7042:同じクライアント ブラウザ セッションが過去 '1' 秒間に '6' リクエストを実行しました
-
27-09-2019 - |
質問
ADFS v2.0(Geneva)のリリース候補バージョンを使用して保護しようとしているASP.NET MVCアプリケーションがあります。アプリケーションを証明書利用者信頼として構成し、Fedutil.exe を使用してアプリケーションの Web.config を変更して、ジュネーブ サーバーに関する情報を保持し、ジュネーブ サーバーをクレーム ソースとして使用するようにしました。
ただし、MVC アプリにアクセスしようとすると、Geneva にリダイレクトされ、その後 (自己署名証明書について警告された後) 再び MVC アプリにリダイレクトされます。両方の自己署名証明書の警告を受け入れた後、2 つのサーバーは無限リダイレクト ループで相互にピンポンを行い、最終的に Geneva が次のメッセージを出力します。
同じクライアント ブラウザ セッションが、過去 '1' 秒間に '6' 件のリクエストを実行しました。構成が間違っている可能性があります。詳細については、管理者にお問い合わせください。
上記のメッセージが含まれるイベントを除き、MVC 側または Geneva 側のイベント ログにエラーはありません。この問題をデバッグ、診断し、できれば修正する方法について誰かが情報を提供していただければ、私は永遠に感謝するでしょう。
繰り返しますが、Geneva ボックスは ADFS v2.0 リリース候補であり、ASP.NET MVC サイトは、WIF SDK の FedUtil.exe を使用して Web.config を変更した Windows Identity Foundation SDK の最新 ('09 年後半) バージョンを使用して構築されました。 。
それで、皆さんもこれで興奮するでしょう...Firefox からこれと同じアプリケーションを試してみました...それは動作します。ドメイン資格情報の入力を求められ、ADFS v2 サーバーによって 1 回リダイレクトされ、最後にアプリケーションのホームページにアクセスして、アカウント名と個人用の挨拶文を入力します。さて、実際の問題は次のとおりです。いったいなぜ IE8 は無限リダイレクト ループに巻き込まれ、Firefox はそうではないのでしょうか??さらにテストを行った結果、Safari と Firefox の両方で、ADFS v2 (RC) または WIF (RTW) のデフォルトのパイプラインを変更することなく、このシナリオをそのまま動作させることができました。IE8 は、この認証シナリオの処理で問題が発生する唯一のブラウザです。自己署名証明書をインストールして信頼すること、ローカル イントラネット ゾーンにサイトを追加すること、セキュリティを低く設定すること、ファースト パーティ Cookie とサード パーティ Cookie を常に許可するように設定することなど、あらゆることを試しました。
解決 2
は、信頼パーティのホスト名がそれにアンダースコア(khoffman_2)を持っていたことが判明します。どうやら、アンダースコアは違法DNSの文字であり、唯一のIEはそれにアンダースコアとの情報を拒否します。
私はkhoffman_2からkhoffman2に私のマシンと改名し、ADFS v2の/ MVC証明書利用者の組み合わせは、Firefox、Safariの、とIE上で完璧に動作します。
他のヒント
私はADFS 1.0で同じ問題を持っていました そして、それを解決するために、私はそれだろう常にFirefoxでの作業だけでなく、IE
「/」URLは、末尾のスラッシュを持っていたことを確認しましたこれはあなたの問題ではありませんが、あなたが説明したものと同じ問題が発生しました。私たちの解決策は次のとおりです。
- IIS で基本認証を有効にしました (これは何も解決しませんでしたが、次の 2 つの手順で必要でした)
- IIS で Windows 認証を無効にする (これにより一部の IE ブラウザの問題が解決されましたが、すべてではありませんでした)
- IIS で匿名アクセスを無効にする (これにより、残りの IE ブラウザの問題は解決されました)
ジャキシディアンの答えは近い。
私の場合、次のことだけを行う必要がありました。
Windows認証 -> 無効
匿名認証 -> 有効
ASP.NET 偽装 -> 無効
フォーム認証 -> 無効
Windows 認証 -> 無効
このループが発生する可能性があります。
私たちはユーザーがUseADFSの設定が設定ファイルに真だった場合提供の請求に基づいて役割にあった場合のチェックが参照するという我々のMVCコントローラのカスタム承認属性を持っていました。私は、この設定がtrueに設定されていたと私は私がページへのアクセスを許可されたグループであったため、ページにアクセスするADFSループを取得保管することを混乱させていたと思っています。
、トラブルシューティングするための鍵は、必ずしも認証を必要とせずに、私のADFSの主張を表示するWebページを作ることだった。
@if (User.Identity.IsAuthenticated)
{
<div>UserName: @User.Identity.Name;</div>
var claimsIdentity = User.Identity as System.Security.Claims.ClaimsIdentity;
<table>
@foreach (var claim in claimsIdentity.Claims)
{
<tr><td>@claim.Type</td><td>@claim.Value</td></tr>
}
</table>
}
私がADFSにログインなっていたことに気づいて、ADFSが動作していたので、私の主張は、セットを取得しました。実際の問題は、私の設定ファイルがUserADFS =基本的に承認に戻りfalseに私のカスタム認証コードを引き起こした「真」の代わりにUseADFS =「true」を持っていました。そのため、ページを再認証するために戻ってADFSに私を転送保たれます。
ユーザーがページにアクセスするための正しい主張を持っていない場合は、とにかく、このADFSは、同様に、ループが発生する可能性がありますログインます。
また、カスタムのauthorize属性を書いた場合はループを防ぐ方法について説明し、次のリンクをチェックしてください。
ネットMVC承認属性を持つとそのリンクからAuthorizeAttributeのカスタムHandleUnauthorizedRequestハンドラのコード:
protected override void HandleUnauthorizedRequest System.Web.Mvc.AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAuthenticated)
{
//One Strategy:
//filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
//Another Strategy:
filterContext.Result = new RedirectToRouteResult(
new RouteValueDictionary(
new
{
controller = "u",
action = "LoginStatus",
errorMessage = "Error occurred during authorization or you do not have sufficient priviliges to view this page."
})
);
}
else
{
base.HandleUnauthorizedRequest(filterContext);
}
}