2014-10-09 2 views
1

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

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

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

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

Update 1:

перед новой проблемой:

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

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

Ниже приведен фрагмент кода, который мы используем для получения сведений о пользователе, однако, много раз мы попадаем в ELSE-часть (ClaimIdentity.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"); 
} 

Пожалуйста, сообщите нам, если нам что-то не хватает.

ответ

2

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

Что искать:

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

Сообщите нам, если это решается! HTH V.

+1

Удаление атрибута Авторизовать, он работает нормально locally.However раз мы разместим его в лазурь, после нескольких попыток входа в системе, мы столкнулись с другим вопросом, где-то, нам вообще не разрешено входить в систему. Данные пользователя не загружаются из-за того, что аутентификация завершается с ошибкой и перенаправляется на страницу с ошибкой (настраиваемая страница) .Below - это часть кода, которую мы используем для получения сведений о пользователе , однако, много раз мы попадаем в ELSE. var requirementsIdentity = User.Identity as ClaimsIdentity; if (ClaimIdentity.IsAuthenticated) {....} else {return RedirectToAction («Ошибка», «Главная»); } –

0

Причина заключается в том, что Cookies Owin хранятся в другом месте и System.Web в другом месте.

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

За дополнительной информацией просьба обращаться к this.

Переконфигурируйте CookieAuthenticationMiddleware писать непосредственно в коллекцию печенья system.web в

Смежные вопросы