ADFS v2.0 Ошибка: MSIS7042: тот же сеанс браузера клиента сделал «6» запросов за последние «1» секунды

Question

Люди, У меня есть приложение ASP.NET MVC, которое я пытаюсь защитить с помощью Release Candidate версии ADFS v2.0 (Женева). Я настроил приложение как доверие доверяющей стороны, и я использовал Fedutil.exe для изменения Web.config приложения, чтобы он имел информацию о сервере в Женеве и использовал сервер Geneva в качестве источника претензий.

Однако, когда я пытаюсь использовать приложение MVC, он перенаправляется в Женеву, после чего (после предупреждения о самоподписанных сертификатах) снова перенаправляет меня в приложение MVC. После принятия обоих самозаверяющих сертификатов сертификатов два сервера играют в пинг-понг друг с другом в бесконечном цикле переадресации, пока, наконец, Женева не извергает следующее сообщение:

Тот же сеанс браузера клиента сделал запросы «6» в последнем '1' секунд. Возможно, будет плохая конфигурация. Для получения дополнительной информации обратитесь к администратору.

В журналах событий на стороне MVC или в Женеве ошибок нет, кроме случая, содержащего вышеуказанное сообщение. Если кто-то может дать мне некоторую информацию о том, как пытаться отлаживать, диагностировать и, надеюсь, исправить эту проблему, я буду бесконечно благодарен.

Опять же, Женевский бокс - это кандидат на выпуск ADFS v2.0, а сайт ASP.NET MVC был создан с использованием последней (поздней версии) версии Windows Identity Foundation SDK с Web.config, измененной с помощью FedUtil.exe из WIF SDK.

---

Итак, вы все получите удовольствие от этого ... Я пробовал это же приложение из Firefox и ... IT WORKS. Я получаю запрос на учетные данные моего домена, сервер ADFS v2 перенаправляет меня ОДИН РАЗ, а затем я попадаю на главную страницу своего приложения, включая имя моей учетной записи и персонализированное приветствие. Итак, настоящая проблема заключается в следующем: почему, черт возьми, IE8 попадает в бесконечный цикл перенаправления, а Firefox НЕ? После еще большего тестирования я смог получить этот сценарий без изменений любого из материалов конвейера по умолчанию из ADFS v2 (RC) или из WIF (RTW) на BOTH Safari AND Firefox. IE8 - это единственный браузер, который может выявить любую проблему, связанную с этим сценарием аутентификации. Я пробовал все, включая установку и доверие к самозаверяющим сертификатам, добавление сайтов в зону локального интрасети и снижение безопасности до минимума и даже установку первых и сторонних файлов cookie, которые всегда разрешены.

Answer 1

Оказывается, что имя хозяина полагающейся стороны имеет в нем символ подчеркивания (khoffman_2). По-видимому, подчеркивание является незаконным символом DNS, и ТОЛЬКО IE будет отклонять информацию с помощью подчеркивания в ней.

Я переименовал свою машину с khoffman_2 в khoffman2, а команда сторонних разработчиков ADFS v2/MVC работает безупречно на Firefox, Safari и IE.

Answer 2

Я была такая же проблема с ADFS 1.0 И решить это, я уверен, что URL был слэши «/», который всегда будет работать в FireFox, а также IE

например: https://somedomain.com/Application_2/

Answer 3

Хотя это не ваша проблема, у нас были одинаковые проблемы с тем, что вы описали.Наше решение было:

1. Enabled обычную проверку подлинности в IIS (это ничего не решало, но требовалось в течение следующих 2 шага)
2. Отключить проверку подлинности Windows в IIS (это решило проблему для некоторых браузеров IE, но не все)
3. Отключить анонимный доступ в IIS (это решило проблему для остальных браузеров IE) ответ

Answer 4

Jaxidian близок.

В моем случае я имел только:

• проверки подлинности Windows -> Disabled

• Anonymous Auth -> Enabled

• ASP.NET Олицетворение -> Disabled

• Формы Auth -> Отключено

• для Windows Auth -> Disabled

Answer 5

Этот цикл может произойти, если пользователь не имеет права доступа к странице.

У нас был специальный атрибут авторизации на нашем MVC-контроллере, который проверяет, был ли пользователь в роли на основе заявлений, если параметр для UseADFS был истинным в файлах конфигурации. Я думал, что этот параметр установлен в true и был сбит с толку, что я продолжал получать петлю adfs при доступе к странице, потому что я был в группах, которым было разрешено доступ к странице.

Ключ к устранению неполадок заключался в том, чтобы сделать веб-страницу, на которой были представлены мои заявки adfs, без необходимости аутентификации.

@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 = «true» вместо UseADFS = «true», что в основном привело к тому, что мой пользовательский код авторизации вернул false при авторизации. Поэтому страница пересылала меня обратно в adfs для повторной аутентификации.

В любом случае, если у пользователя нет правильной заявки на доступ к странице, тогда может возникнуть и этот цикл входа adfs.

Кроме того, если вы написали специальный атрибут авторизации, обязательно проверьте следующую ссылку, которая описывает, как предотвратить цикл.

Redirect loop with .Net MVC Authorize attribute with ADFS Claims

Пользовательского HandleUnauthorizedRequest коды обработчика для AuthorizeAttribute из этой ссылки:

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