ADFS Error v2.0: MSIS7042: The same client browser session made "6" requests in the last "1" second

Question

Folks, I have an ASP.NET MVC application that I am trying to protect using the Candidate version of ADFS v2.0 (Geneva). I configured the application as a trust of trusted parties, and I used Fedutil.exe to modify the Web.config application so that it had information about the server in Geneva and used the Geneva server as the source of its claims.

However, when I try to use the MVC application, it redirects to Geneva, after which (after warning me about self-signed certificates) it redirects me to the MVC application again. After accepting both self-signed certificate certificates, the two servers play ping-pong with each other in an endless redirect cycle, until, finally, Geneva spews the following message:

The same client browser session made "6" requests in the last "1" second. Perhaps there will be a bad configuration. Contact your administrator for more information.

There are no errors in the event logs on the MVC side or in Geneva, except for the case containing the above message. If someone could give me some information on how to try to debug, diagnose and, hopefully, fix this problem, I will be eternally grateful.

Again, the Geneva Field is a candidate for the release of ADFS v2.0, and the ASP.NET MVC site was created using the latest (late) version of the Windows Identity Foundation SDK with Web.config modified with FedUtil.exe. WIF SDK.

---

So, you all will enjoy this ... I tried the same application from Firefox and ... IT WORKS. I get a request for the credentials of my domain, the ADFS v2 server redirects me ONCE, and then I get to the main page of my application, including my account name and personalized greeting. So, now the real problem is this: why the hell does IE8 end up in an endless redirect loop, and Firefox NOT? After even more testing, I was able to get this script unchanged, without changing any default material from ADFS v2 (RC) or from WIF (RTW) to BOTH Safari AND Firefox. IE8 is the only browser that can detect any problem associated with this authentication scenario. I tried everything, including installation and trust in self-signed certificates, adding sites to the local intranet zone and reducing security to a minimum, and even setting the first and third-party cookies, which are always allowed.

Answer 1

It turns out that the host name of the relying party has an underscore in it (khoffman_2). The underscore appears to be an illegal DNS character, and IE will ONLY reject information with underscores in it.

I renamed my machine from khoffman_2 to khoffman2, and the team of third-party ADFS v2 / MVC users works flawlessly in Firefox, Safari and IE.

Answer 2

I had the same problem with ADFS 1.0 And to resolve this, I made sure that the URL has an end slash "/", which will always work in FireFox, as well as IE

e.g. https://somedomain.com/Application_2/

Answer 3

Although this is not your problem, we had the same problems with what you described. Our solution was as follows:

• Basic authentication is enabled in IIS (this did not solve anything, but was required for the next 2 steps)
• Disable Windows authentication in IIS (this resolved the issue for some IE browsers, but not for all)
• Disable anonymous access in IIS (this solved the problem for other IE browsers)

Answer 4

The Yasidian answer is close.

In my case, I only had to:

• Windows Authentication -> Disabled

• Anonymous Auth → Enabled

• Avatar ASP.NET -> Disabled

• Forms Auth → Disabled

• Windows Auth → Disabled

Answer 5

This cycle may occur when the user does not have access to the page.

We had our own authorization attribute on our MVC controller, which checks if the user was in the role based on the statements if the parameter for UseADFS was true in the configuration files. I thought this parameter was set to true and was confused that I continued to get the adfs loop when accessing the page because I was in groups that were allowed access to the page.

The key to troubleshooting was to make a web page displaying my adfs ads without the need for authentication.

@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> } 

I noticed that I logged into ADFS and my requirements were set, so ADFS worked. The actual problem was that in my configuration file UserADFS = "true" instead of UseADFS = "true", which basically led to the fact that my user authorization code returned false during authorization. So the page sent me back to adfs for re-authentication.

In any case, if the user does not have the correct requirements to access the page, then this adfs login loop may also occur.

In addition, if you wrote a special authorize attribute, be sure to check the following link that describes how to prevent the loop.

Forward the loop with the .Net MVC Authorize attribute with ADFS requirements

Custom HandleUnauthorizedRequest handler code for AuthorizeAttribute at this link:

  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); } }