← Ко всем статьям

Что такое SAML и как работает SAML-аутентификация

SAML — XML-стандарт обмена данными об аутентификации между провайдером идентичности и приложением. Разбираем механику assertion, сильные и слабые стороны, сравнение с OIDC.

SAML (Security Assertion Markup Language) — открытый стандарт, по которому провайдер идентичности сообщает приложению, что пользователь успешно прошёл проверку. Это один из двух основных протоколов единого входа наряду с OIDC.

Ключевой элемент SAML — assertion: подписанный XML-документ, где сказано, кто пользователь, когда он вошёл и какими атрибутами обладает. Приложение проверяет подпись и доверяет содержимому.

Участники обмена

Identity Provider (IdP) — сторона, которая проверяет учётные данные и выпускает assertion.

Service Provider (SP) — приложение, которому нужно узнать пользователя. Своей проверки учётных данных оно не выполняет.

Пользователь — тот, кто входит; его браузер выступает посредником, передавая сообщения между IdP и SP.

Как проходит вход

  1. Пользователь открывает приложение (SP).
  2. Приложение не знает пользователя и перенаправляет его к провайдеру идентичности.
  3. Провайдер проверяет учётные данные — либо запрашивает их, либо использует уже активную сессию.
  4. Провайдер формирует assertion, подписывает его и передаёт приложению через браузер пользователя.
  5. Приложение проверяет подпись, срок действия и получателя, после чего открывает доступ.

Обмен занимает доли секунды и для пользователя выглядит как несколько мгновенных перенаправлений.

Что внутри assertion

Помимо самого факта аутентификации, assertion переносит атрибуты пользователя: адрес электронной почты, отображаемое имя, принадлежность к группам, должность. Приложение использует их, чтобы создать локальный профиль и определить уровень доступа.

Именно поэтому корректная настройка сопоставления атрибутов важна не меньше самой интеграции: если группа передаётся не в том поле, пользователь войдёт, но окажется без прав или, что хуже, с лишними.

Сильные стороны

Зрелость. Стандарт существует давно, поддержка есть практически во всех корпоративных системах — включая те, которые больше не развиваются.

Богатая передача атрибутов. Assertion способен перенести подробный набор данных о пользователе за один обмен.

Централизация. Как и любой единый вход, SAML убирает разрозненные пароли и упрощает отзыв доступа.

Слабые стороны

XML. Формат многословный, разбор тяжелее, а исторические уязвимости в обработке XML-подписей — отдельная тема, требующая аккуратных библиотек и своевременных обновлений.

Мобильные приложения. Схема рассчитана на браузерные перенаправления, за пределами браузера она работает неуклюже.

Сертификаты. Подписи опираются на сертификаты, у которых есть срок действия. Просроченный сертификат провайдера роняет вход во все подключённые приложения разом — классическая причина внезапных инцидентов.

Трудоёмкая отладка. Ошибки проявляются как невнятный отказ на стороне приложения; чтобы понять причину, нужно разбирать содержимое assertion.

SAML или OIDC

Критерий SAML OIDC
Формат XML JSON
Год появления 2005 (версия 2.0) 2014
Мобильные приложения Плохо приспособлен Полноценная поддержка
API Не предназначен Родная область применения
Сложность интеграции Высокая Низкая
Распространённость в корпоративных системах Очень высокая Растёт

Практический вывод: новые интеграции разумно делать на OIDC, а SAML оставить для систем, которые другого не умеют. Полный отказ от SAML в средней организации — вопрос не одного года, и это нормально.

Что важно при эксплуатации

Следите за сроком сертификатов. Заведите напоминание заранее, а не за день. Обновление сертификата требует согласованных действий с каждым подключённым приложением.

Используйте только HTTPS. Assertion передаётся через браузер, и незащищённый канал делает бессмысленной саму подпись.

Проверяйте получателя. Assertion, выпущенный для одного приложения, не должен приниматься другим.

Ограничивайте срок действия. Короткое окно валидности снижает риск повторного использования перехваченного документа.

Как это устроено в Keydee

Keydee выступает провайдером идентичности для ваших приложений, а основным протоколом подключения является OIDC — он проще в интеграции, надёжнее в мобильных сценариях и не требует обслуживания сертификатов на стороне каждого приложения.

Что это даёт:

  • Подключение приложения занимает минуты, а не согласование метаданных и обмен сертификатами.
  • Единая политика MFA для всех приложений организации.
  • Управление сессиями с возможностью завершить любую активную сессию.
  • Журнал входов с фиксацией реального IP-адреса.

Если у вас есть системы, работающие только по SAML, спланируйте их как отдельный этап миграции: обычно они переводятся последними или остаются на прежней схеме до вывода из эксплуатации.

Покажем платформу на вашем сценарии за 30 минут

Никаких длинных презентаций. Покажем, как KeyDee работает именно для вашего продукта — и ответим на все технические вопросы.

Свяжемся в течение 2 часов · Размещение данных в РФ · ФЗ-152

Оставить заявку

Ответим в течение 2 часов в рабочее время