ADFS v2.0 Error : MSIS7042: The same client browser session has made '6' requests in the last '1' seconds

Question

Folks, I've got an ASP.NET MVC application that I am attempting to secure using the Release Candidate version of ADFS v2.0 (Geneva). I have configured the application as a relying party trust, and I've used Fedutil.exe to modify the application's Web.config so that it has the information about the Geneva server and uses the Geneva server as its claims source.

However, when I try and hit the MVC app, it redirects to Geneva, which then (after warning me about self-signed certs) re-directs me to the MVC app again. After accepting both self-signed cert warnings, the two servers play ping-pong with each other in an infinite redirect loop until finally Geneva spews the following message:

The same client browser session has made '6' requests in the last '1' seconds. There could be a possible bad configuration. Contact your administrator for details.

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

Again, the Geneva box is the ADFS v2.0 Release Candidate and the ASP.NET MVC site was built using the latest (late '09) version of the Windows Identity Foundation SDK with Web.config modified using FedUtil.exe from the WIF SDK.

---

So you will all get a kick out of this... I tried this same application from Firefox and ... IT WORKS. I get prompted for my domain credentials, the ADFS v2 server re-directs me ONCE and then I end up on the home page of my application, complete with my account name and personalized greeting. So now the real issue is this: Why the hell is IE8 getting caught in an infinite redirect loop and Firefox ISN'T ?? After even further testing, I've been able to get this scenario working, out of the box, without modification of any of the default pipeline stuff from ADFS v2 (RC) or from WIF (RTW) on BOTH Safari AND Firefox. IE8 is the ONLY browser to exhibit any problem dealing with this authentication scenario. I've tried everything, including installing and trusting the self-signed certs, adding the sites to my local intranet zone and dropping security to low and even setting first AND third party cookies to always allow.

Answer 1

Turns out that the host name of the relying party had an underscore in it (khoffman_2). Apparently, the underscore is an illegal DNS character and ONLY IE will reject the information with the underscore in it.

I renamed my machine from khoffman_2 to khoffman2 and the ADFS v2/MVC relying party combination works flawlessly on Firefox, Safari, AND IE.

Answer 2

I had the same issue with ADFS 1.0 And to resolve it, I made sure that the URL had a trailing forward slash "/" that would always work in FireFox as well as IE

eg : https://somedomain.com/Application_2/

Answer 3

While this isn't your problem, we have had identical problems to what you described. Our solution was to:

1. Enabled Basic Authentication in IIS (this solved nothing but was required for the next 2 steps)
2. Disable Windows Authentication in IIS (this solved the problem for some IE browsers but not all)
3. Disable Anonymous Access in IIS (this solved the problem for the rest of the IE browsers)

Answer 4

Jaxidian's answer is close.

In my case I only had to:

• Windows Authentication -> Disabled

• Anonymous Auth -> Enabled

• ASP.NET Impersonation -> Disabled

• Forms Auth -> Disabled

• Windows Auth -> Disabled

Answer 5

This loop can occur when a user is not authorized to access a page.

We had a custom authorization attribute on our MVC controller that checks to see if the user was in a role based on the claims provided if the setting for UseADFS was true in the config files. I thought this setting was set to true and was confounded that I kept getting the adfs loop when accessing the page because I was in the groups that were authorized to access the page.

The key to troubleshooting was to make a web page that displayed my adfs claims without necessarily requiring 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 was getting logged into ADFS, and my claims were getting set, so ADFS was working. The actual issue was my config file had UserADFS="true" instead of UseADFS="true" which basically caused my custom authorization code to return false on authorization. Therefore, the page kept forwarding me back to adfs to authenticate again.

Anyways, if a user does not have the correct claims to access the page, then this adfs login loop can occur, as well.

Also, if you wrote a custom authorize attribute be sure to check out the following link which describes how to prevent the loop.

Redirect loop with .Net MVC Authorize attribute with ADFS Claims

Custom HandleUnauthorizedRequest handler code for AuthorizeAttribute from that 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);
        }
    }