SAML-ошибки подписи выглядят сложно, но обычно сводятся к несоответствию настроек между Identity Provider и Service Provider.
Почему возникает проблема
Подпись может отклоняться из-за старого сертификата, неправильных metadata, изменения ACS URL, расхождения времени, другого алгоритма подписи или неверного формата NameID.
Что проверяю
- Какой сертификат использует IdP.
- Совпадают ли metadata у IdP и SP.
- Правильный ли ACS URL.
- Нет ли расхождения времени на серверах.
- Какой именно элемент подписан: response или assertion.
Как решаю задачу
Я сверяю SAML-пакет не по догадкам, а по фактическому XML и metadata. Важно понять, что именно проверяется и каким сертификатом.
- Собираю SAML response из браузера или логов.
- Проверяю сертификат и алгоритм подписи.
- Сверяю ACS URL и Entity ID.
- Обновляю metadata при необходимости.
- Тестирую вход через SSO на отдельном пользователе.
Что будет на выходе
- SSO проходит проверку подписи.
- Настройки IdP и SP совпадают.
- Ошибки входа становятся понятнее.
- Можно безопасно подключать новых пользователей.
Что подготовить
- Название IdP и приложения.
- Metadata IdP и SP.
- Текст ошибки.
- Тестовый пользователь для входа.
Вопросы и ответы
Можно ли отключить проверку подписи?
Для production это плохая идея. Нужно исправить сертификаты и metadata.
Почему ошибка появилась внезапно?
Часто истек или сменился сертификат IdP.
Нужна похожая задача?
Опишите, что именно не работает и где это видно. Я быстро разберу симптомы, проверю техническую причину и предложу понятный план исправления без лишних созвонов и затяжки.