it-swarm.com.ru

OWIN OpenIdConnect Middleware IDX10311 не может быть проверен

У меня есть приложение, использующее промежуточное ПО OWIN для OpenIdConnect. Файл startup.cs использует стандартную реализацию app.UseOpenIdConnectAuthentication. Файл cookie настроен для браузера, но он содержит ошибки:

IDX10311: RequireNonce имеет значение true (по умолчанию), но validationContext.Nonce имеет значение null. Одноразовый номер не может быть подтвержден. Если вам не нужно проверять одноразовый номер, установите OpenIdConnectProtocolValidator.RequireNonce в значение «false».

Я обнаружил, что при запуске Fiddler, как и для большинства отладочных проектов, такое поведение происходит. Ошибка возвращается, но если я возвращаюсь на сайт, все работает, и мой пользователь проходит проверку подлинности. Кто-нибудь видел такое поведение при запуске скрипача?

С фидлером:

  • SecurityTokenValidated уведомление в OpenIdConnect выполняется дважды.
  • После второго прохода через IDX10311 выдается ошибка
  • Браузер содержит действительный файл cookie, возвращаясь к странице, я могу просмотреть действительные данные User.Identity.

Работает без скрипача:

  • SecurityTokenValidated выполняется один раз в OpenIdConnect
  • Ошибка не выдается, продолжается загрузка действия контроллера для URI перенаправления после аутентификации
  • Cookie также действителен и данные User.Identity верны.

Идеи? Я могу обойти это без запуска fiddler, но при отладке было бы неплохо также запустить fiddler для проверки трафика.

11
gilm0079

У меня была та же проблема, но переключение Microsoft.Owin.Security.OpenIdConnect на версию 3.0.1 решило проблему

5
Jek

Может быть, это причина?

Здравствуйте, я думаю, что нашел основную причину этой проблемы.

Я подытоживаю свои открытия:

  1. Проблема в файле cookie OpenIdConnect.nonce.OpenIdConnect

  2. Этот файл cookie устанавливается из приложения (давайте назовем его «ID Client»), как только промежуточное ПО OpenID инициирует сеанс аутентификации.

  3. Файл cookie должен быть отправлен обратно из браузера на «ID Client», как только аутентификация будет завершена. Я предполагаю, что этот файл cookie необходим для двойной проверки с точки зрения клиента ID (т.е. действительно ли я запустил процесс авторизации OpenID Connect?)

  4. Много путаницы во мне было вызвано термином «Nonce», используемым как в этом файле cookie, так и в потоке OpenID Connect с сервера ID. 

  5. Исключение, в моем случае, было вызвано отсутствующим файлом cookie (не одноразовым номером сервера ID), просто потому, что браузер не отправил его обратно «клиенту идентификатора»

Таким образом, основной корень, в моем случае, был следующим: файл cookie OpenIdConnect.nonce.OpenIdConnect не был отправлен обратно клиенту идентификатора браузером. В некоторых случаях (например, Chrome, Firefox и Edge) cookie отправлялся правильно, а в других (IE11, Safari) - нет.

После долгих исследований я обнаружил, что проблема заключается в политике ограничения Cookie, определенной в браузере. В моем случае «идентификатор клиента» встроен в <iframe>. Это приводит к тому, что «ID Client» будет рассматриваться как «сторонний клиент», поскольку пользователь не переходил по этому URL-адресу непосредственно в главном окне. Поскольку это сторонние устройства, для некоторых браузеров его куки-файлы должны быть заблокированы. На самом деле тот же эффект можно получить в Chrome, установив параметр «Блокировать сторонние куки-файлы».

Итак, я должен сделать вывод, что:

a) Если iframe является обязательным (как в моем случае, потому что «ID-клиенты» - это приложения, которые должны выполняться внутри графического содержимого нашего основного приложения платформы), я думаю, что единственное решение - перехватить ошибку и обработать ее с помощью страница с просьбой включить сторонние файлы cookie.

б) Если iframe не обязателен, достаточно открыть «ID Client» в новом окне.

Надеюсь, это кому-нибудь поможет, потому что я сошел с ума!

Marco

5
Marconline

Я знаю, что это старая статья, но у меня была эта проблема, и у меня ничего не получалось, после того, как я сошел с ума от решения, позволяющего сделать мое корпоративное приложение работоспособным, я в конечном итоге исправил его, установив для параметра multi-tenanted значение yes в Azure (в Azure выберите: регистрация приложения> настройки> свойства, установите для нескольких пользователей значение yes и нажмите «Сохранить».

надеюсь, что это кому-то поможет, никто не заметил.

2
pau Fer

Для меня изменение URL ответа в Azure Active Directory работает.

Это происходит, когда вы включаете SSL, потому что он изменяет только URL-адрес входа на URL-адрес HTTPS, а URL-адрес ответа остается тем же URL-адресом HTTP.

Когда вы пытаетесь получить доступ к своему приложению, используя URL-адрес https, он устанавливает в вашем браузере файл cookie с уникальным номером (nonce) и обращается к Azure AD для проверки подлинности. После аутентификации браузер должен предоставить доступ к этому cookie. Но поскольку URL-адрес и URL-адрес ответа различаются, браузер не распознает ваше приложение и не предоставляет доступ к этому cookie, и, следовательно, приложение выдает эту ошибку.

1
ABB

Временное решение, которое работало для меня для приложения, защищенного через Azure Active Directory, состояло в том, чтобы выйти из системы (перейдя на страницу sites/Account/SignOut), а затем я смог вернуться на домашнюю страницу и войти в систему в порядке. Надеюсь, это кому-нибудь поможет.

0
patrickL

Я заметил эту ошибку при запуске IIS Express в фоновом режиме, когда я переключился на хостинг в полном IIS. Когда я отключил IIS Express, моя ошибка исчезла.

0
ebol2000

Правило перезаписи файлов cookie в файле web.config, чтобы гарантировать, что файлы cookie того же сайта дали это загадочное исключение. Отключение этого правила решило это.

0
Dirk Vermeer