Ошибка AzureAD AADSTS7500525 при использовании плагина SAML

Привет!!

Плагины SAML работали с нашим AzureAD, но вчера после обновления до последнего коммита мы начали видеть следующие ошибки при попытке пользователей пройти аутентификацию через SAML:

Вход
Извините, но у нас возникли проблемы с входом.

AADSTS7500525: В сообщении SAML произошла ошибка XML в строке 1, позиция 1. Проверьте, соответствует ли содержимое XML сообщений SAML спецификациям протокола SAML.

Эта ссылка Azure AD SAML2 request rejected: AADSTS7500525 - Microsoft Q&A предполагает, что это может быть вызвано «сжатыми запросами аутентификации SAML», которые AzureAD не поддерживает.

В коммитах декабря было много изменений в SAML (например, конфигурация через настройки сайта), но я не смог понять, было ли какое-то изменение, связанное с запросами SAML, которое могло вызвать эту проблему.

Конфигурация SAML (работала нормально до обновления):

## Настройки плагина SAML
  DISCOURSE_SAML_TARGET_URL: https://login.microsoftonline.com/<<our app id>>/saml2
  DISCOURSE_SAML_CERT_FINGERPRINT: "<<our fingerprint>>"
  DISCOURSE_SAML_REQUEST_METHOD: POST
  #DISCOURSE_SAML_FULL_SCREEN_LOGIN: true
  DISCOURSE_SAML_CERT: "-----BEGIN CERTIFICATE-----
<<Our cert payload>>
-----END CERTIFICATE-----"
  DISCOURSE_SAML_SYNC_GROUPS: true
  DISCOURSE_SAML_GROUPS_ATTRIBUTE: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
  DISCOURSE_SAML_GROUPS_FULLSYNC: true

Как я могу включить отладку аутентификации, чтобы получить больше информации об этом?

Сожалеем, что у вас возникли проблемы! Вы правы: в последние несколько недель я занимался активной рефакторингом плагина SAML, поэтому это может быть связано.

Когда это происходит? Когда пользователи инициируют вход или когда их возвращают на Discourse?

Есть ли возможность поделиться здесь URL вашего сайта или отправить его в личные сообщения?

Это происходит каждый раз, когда пользователю необходимо войти в систему (сессия истекла или новый пользователь пытается войти).

Это началось после обновления до ревизии 9334abe249 (ранее была версия 959923d3cf).

Извините, но наш форум размещён внутренне в приватном аккаунте AWS, поэтому вы не сможете получить к нему доступ извне нашей сети.

Где появляется ошибка? В логах Discourse? На экране пользователя? В Azure?

Могли бы вы предоставить несколько скриншотов?

Я также пытался найти что-то в логах Discourse, но поскольку ошибка возникает на стороне Azure, я не нашел там никаких сообщений об ошибке.

В production.log процесс входа останавливается здесь (вероятно, в ожидании ответа от Azure):

Processing by StaticController#show as HTML
Parameters: {“id”=>“login”}
Rendered static/login.html.erb (Duration: 17.5ms | Allocations: 1440)
Completed 200 OK in 19ms (Views: 18.3ms | ActiveRecord: 0.0ms | Allocations: 2104)
Started GET “/session/csrf” for <> at 2021-12-14 18:28:16 -0300
Processing by SessionController#csrf as JSON
Completed 200 OK in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 337)
Started POST “/auth/saml” for <> at 2021-12-14 18:28:16 -0300
(saml) Setup endpoint detected, running now.
(saml) Request phase initiated.

Команда, отвечающая за Azure, пытается получить XML, который они получают, чтобы, возможно, мы могли увидеть что-то «отличное» в нем. Я сообщу вам, когда они пришлют мне данные.

Ошибка возникает после того, как пользователь нажимает кнопку входа.
Затем он перенаправляется на страницу входа Azure со следующим сообщением об ошибке:

Боюсь, без доступа к сайту сложно понять, что здесь происходит.

Следующим шагом будет попытка получить XML, который поступает в Azure, и определить, в чём проблема. Вы можете сделать это, проверив полезную нагрузку в инструментах разработчика браузера, а затем декодировав её с помощью инструмента, например этого

Отлично!

Ответ запроса — код HTTP 400:

Request URL: https://login.microsoftonline.com/APP_ID/saml2
Request method: POST
Status code: 400 Bad Request
Remote address: 20.190.173.144:443
Referrer policy: strict-origin-when-cross-origin

Декодированный SAMLRequest (некоторые идентификаторы скрыты в целях конфиденциальности):

<samlp:AuthnRequest AssertionConsumerServiceURL='https://INTERNAL_URL/auth/saml/callback' Destination='https://login.microsoftonline.com/APP_ID/saml2' ID='_11111111-1111-1111-1111-111111111111' IssueInstant='2021-12-14T22:33:29Z' Version='2.0' xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion' xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'><saml:Issuer>https://INTERNAL_URL</saml:Issuer></samlp:AuthnRequest>

Одно из замеченных мною отличий между моим запросом и примером на Single sign-on SAML (Security Assertion Markup Language) protocol - Microsoft identity platform | Microsoft Learn заключается в том, что в моем запросе AuthnRequest отсутствует параметр

xmlns="urn:oasis:names:tc:SAML:2.0:metadata"

Похоже, что в результате недавнего рефакторинга я по ошибке добавил сжатие для привязки SAML POST. Я откатил это изменение в FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub

Пожалуйста, попробуйте обновить плагин SAML и посмотрите, станет ли всё работать лучше.

Привет, Дэвид,

После обновления до FIX: Do not compress SAML request for POST binding (#55) · discourse/discourse-saml@792a51c · GitHub аутентификация SAML здесь снова работает как обычно.

Спасибо за помощь и за всю работу над плагином!