Приложение Owin и katana после нескольких попыток входа в систему.claimsIdentity IsAuthenticated FALSE

Мы используем аутентификацию Microsoft Owin для нашего приложения, которое перенаправит пользователя на страницу входа в Azure Active Directory. После успешного входа в систему будет отображаться домашняя страница нашего приложения.

Это будет работать без каких-либо проблем несколько раз. Однако после нескольких попыток, если я попытаюсь снова войти в систему, после нажатия кнопки ВХОД (на странице входа в Azure Active Directory) он не будет перенаправлен на нашу домашнюю страницу. Он загружает пустую страницу, никогда не заканчивает загрузку и зависает. В адресной строке отображается переключение запросов между нашей домашней страницей и страницей входа в Azure.

Ниже приведен код, используемый для входа:

 public void SignIn()
 {
     if (!Request.IsAuthenticated)
     {
         HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/Home/Index" }, OpenIdConnectAuthenticationDefaults.AuthenticationType);
     }
 }

Обновление 1:

столкнулся с новой проблемой:

Здравствуйте, Витторио,

Спасибо!!! для вашего ответа. Как вы упомянули, после удаления атрибута Authorize он отлично работает локально (из исходного кода). Однако, как только мы развернем его на Azure, после нескольких попыток входа в систему мы столкнемся с другой проблемой, где нам вообще не разрешен вход в систему. Сведения о пользователе не загружаются из-за сбоя аутентификации и перенаправления на страницу с ошибкой (пользовательская страница).

Ниже приведен фрагмент кода, который мы используем для получения сведений о пользователе, однако много раз мы попадаем в часть ELSE (claimsIdentity.IsAuthenticated возвращает FALSE).

var claimsIdentity = User.Identity as ClaimsIdentity;
if (claimsIdentity.IsAuthenticated) {
    accesstoken = claimsIdentity.FindAll("urn:accesstoken:access_token").FirstOrDefault().Value;
    domainname = claimsIdentity.FindAll("urn:appdomain:domain").FirstOrDefault().Value;
} else {
    return RedirectToAction("Error", "Home");
}

Пожалуйста, дайте нам знать, если мы что-то упустили.


azure claims owin asp.net-mvc-4 katana
person Purushothama Ramrao    schedule 09.10.2014    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Судя по вашему описанию, вы испытываете цикл, в котором поток постоянно переходит в Azure AD и обратно в ваше приложение. Это правильно? Обычно это происходит, когда вы пытаетесь получить доступ к одному ресурсу, который требует аутентификации/авторизации (например, через оформление [Авторизация]), и у вас есть некоторое состояние, которое автоматически аутентифицирует вас с пользователем, который не удовлетворяет требованиям контроля доступа к ресурсу, вызывая другое перенаправление и запуск нового цикла.

Что искать:

  • ресурсы, украшенные [Authorize()]. У вас может быть действительный токен для пользователя, который не удовлетворяет условию. Решение: внедрить собственный фильтр, возвращающий 403 вместо 401 при проблемах с авторизацией.
  • в то время как вы вошли в приложение, вы вышли из Azure AD и вошли с другим пользователем Azure AD из другого каталога. Если вам нужно иметь возможность сделать это, вам, вероятно, следует установить промежуточное ПО в пассивное состояние (через AuthenticationMode = AuthenticationMode.Passive), чтобы ошибки 401 не запускали автоматически обращения к Azure AD. Обратите внимание, что это может работать и для вышеуказанного

Дайте нам знать, если это решит! ХТ В.

person vibronet    schedule 13.10.2014
comment
Удалив атрибут Authorize, он отлично работает локально. Однако, как только мы развернем его на Azure, после нескольких попыток входа в систему мы столкнемся с другой проблемой, где нам вообще не разрешен вход в систему. Данные пользователя не загружаются. из-за чего аутентификация завершается сбоем и выполняется перенаправление на страницу с ошибкой (пользовательскую страницу). Ниже приведен фрагмент кода, который мы используем для получения сведений о пользователе, однако много раз мы попадаем в часть ELSE. var ClaimsIdentity = User.Identity as ClaimsIdentity; if (claimsIdentity.IsAuthenticated){ .... } else { return RedirectToAction(Error, Home); } - person Purushothama Ramrao; 14.10.2014

arrow_upward
0
arrow_downward

Причина в том, что Owin хранит файлы cookie в другом месте, а System.Web — в другом месте.

В OWIN коллекция заголовков ответов является основным местом хранения файлов cookie ответов. Однако System.Web сохраняет файлы cookie ответов в отдельной коллекции HttpContext.Response.Cookies, а затем записывает их в коллекцию Response.Headers непосредственно перед отправкой ответа. Это может вызвать конфликт OWIN, если оба подхода используются для одного и того же запроса, так как коллекция Response.Cookies перезапишет все файлы cookie, установленные с помощью заголовков ответов OWIN.

Подробнее см. в этой.

Перенастройте CookieAuthenticationMiddleware для записи непосредственно в коллекцию файлов cookie System.Web.

person Rahul Mohan    schedule 08.03.2016