Ошибка ADFS v2.0:MSIS7042:В одном и том же сеансе клиентского браузера было выполнено «6» запросов за последнюю «1» секунду.
-
27-09-2019 - |
Вопрос
Люди, у меня есть приложение ASP.NET MVC, которое я пытаюсь обеспечить, используя версию ADFS v2.0 (Женева).Я настроил приложение как доверенную сторону и использовал Fedutil.exe для изменения файла Web.config приложения, чтобы оно содержало информацию о женевском сервере и использовало женевский сервер в качестве источника утверждений.
Однако, когда я пытаюсь запустить приложение MVC, оно перенаправляется в Женеву, которая затем (после предупреждения меня о самоподписанных сертификатах) снова перенаправляет меня в приложение MVC.После принятия обоих предупреждений самоподписанного сертификата два сервера играют друг с другом в пинг-понг в бесконечном цикле перенаправления, пока, наконец, Женева не выдаст следующее сообщение:
В одном и том же сеансе браузера клиента было выполнено «6» запросов за последнюю «1» секунду.Возможно, это неправильная конфигурация.Для получения подробной информации обратитесь к своему администратору.
В журналах событий на стороне MVC или в Женеве нет ошибок, за исключением события, содержащего указанное выше сообщение.Если бы кто-нибудь мог дать мне некоторую информацию о том, как попробовать отладить, диагностировать и, надеюсь, устранить эту проблему, я был бы бесконечно благодарен.
Опять же, Женевский ящик — это версия-кандидат ADFS v2.0, а сайт ASP.NET MVC был создан с использованием последней (конца 2009 года) версии Windows Identity Foundation SDK с Web.config, измененным с помощью FedUtil.exe из WIF SDK. .
Так что вы все получите от этого удовольствие...Я попробовал это же приложение из Firefox и...ОНО РАБОТАЕТ.Мне предлагается ввести учетные данные моего домена, сервер ADFS v2 перенаправляет меня ОДИН РАЗ, а затем я оказываюсь на домашней странице своего приложения с именем моей учетной записи и персонализированным приветствием.Итак, теперь реальная проблема заключается в следующем:Какого черта IE8 попадает в бесконечный цикл перенаправления, а Firefox НЕТ?После дальнейшего тестирования мне удалось заставить этот сценарий работать прямо из коробки, без изменения каких-либо компонентов конвейера по умолчанию из ADFS v2 (RC) или из WIF (RTW) как в Safari, так и в Firefox.IE8 — ЕДИНСТВЕННЫЙ браузер, в котором возникают проблемы с этим сценарием аутентификации.Я перепробовал все, включая установку и доверие к самозаверяющим сертификатам, добавление сайтов в зону локальной интрасети, понижение уровня безопасности до низкого уровня и даже настройку основных и сторонних файлов cookie, чтобы они всегда разрешались.
Решение 2
Оказывается, что имя хоста полагающейся стороны имела подчеркивание в нем (Khoffman_2). По-видимому, подчеркивание является незаконным характером DNS и только IE отклонит информацию с подчеркиванием в нем.
Я переименован в машину от Khoffman_2 до Khoffman2, а комбинация ADFS V2 / MVC полагаясь, что ценительная комбинация не работает на Firefox, Safari и IE.
Другие советы
У меня была такая же проблема с ADFS 1.0 и решить ее, я убедился, что у URL-адреса была продвигаемая стрелка «/», которая всегда будет работать в Firefox, а также IE
Например: https://somedomain.com/application_2/
Хотя это не ваша проблема, у нас были идентичные проблемы к тому, что вы описали. Наше решение было:
- Включена базовая аутентификация в IIS (это не решено ничего, кроме как требовалось для следующих 2 шагов)
- Отключить аутентификацию Windows в IIS (это решило проблему для некоторых браузеров IE, но не все)
- Отключить анонимный доступ в IIS (это решило проблему для остальных браузеров IE)
Ответ Джаксидиана близко.
В моем случае мне пришлось только:
Аутентификация Windows -> Отключено
Anonymous Auth -> включен
ASP.NET Embersonation -> отключен
Формы auth -> отключен
Windows Auth -> отключен
Этот цикл может возникнуть, когда пользователю не разрешен доступ к странице.
У нас был настраиваемый атрибут авторизации на нашем контроллере 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.
Кроме того, если вы написали собственный атрибут авторизации, обязательно ознакомьтесь со следующей ссылкой, которая описывает, как предотвратить цикл.
Цикл перенаправления с атрибутом авторизации .Net MVC с утверждениями ADFS
Пользовательский код обработчика 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);
}
}