SAML убирает из приложения пароль, но не проверку доверия

https://www.youtube-nocookie.com/embed/OI_Se_bRfHo

Автор: Listen IT · YouTube · статья Nixys

---

При входе через SAML приложение не получает пароль пользователя. Вместо него оно получает XML-документ, в котором Identity Provider утверждает, что пользователь прошёл аутентификацию. Теперь безопасность зависит от того, насколько строго приложение проверяет это утверждение.

Ролик Listen IT объясняет основные роли SAML. Service Provider представляет приложение, Identity Provider проверяет пользователя, а браузер переносит SAML-запросы и ответы между ними. Благодаря установленному доверию один вход у IdP может открыть доступ к нескольким независимым приложениям.

Это хорошее введение в SAML SSO, но реальный протокол сложнее показанной схемы. Недостаточно найти в ответе имя пользователя: Service Provider должен проверить цифровую подпись, отправителя, получателя, срок действия и другие ограничения assertion.

Кому смотреть: разработчикам, которым предстоит впервые подключать корпоративный SAML-вход и нужно понять роли IdP, SP и браузера.

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

---

В SP-initiated сценарии пользователь сначала открывает защищённую страницу приложения. Service Provider формирует запрос и через браузер отправляет пользователя к Identity Provider. IdP проводит аутентификацию, создаёт SAML response и возвращает его приложению, обычно через автоматическую отправку HTML-формы.

Внутри находится assertion — набор утверждений о пользователе и событии аутентификации. Он может содержать идентификатор, атрибуты, время действия и ограничения по аудитории. Service Provider проверяет сообщение и на его основании создаёт локальную сессию.

На упрощённых схемах эта последовательность выглядит как обмен двумя XML-документами. В production появляются сертификаты, подписи, metadata, clock skew, разные bindings и защита от повторного использования сообщения. Ошибка в любой из этих проверок способна превратить доверие к IdP в обход аутентификации.

Сравнение «SAML отвечает за аутентификацию, OAuth — за авторизацию» полезно для первого знакомства, но не описывает все возможности стандартов. SAML assertion способен передавать атрибуты, которые приложение использует при авторизации. OAuth 2.0, наоборот, не предназначен для установления личности пользователя без дополнительного протокола вроде OpenID Connect.

SAML избавляет каждое приложение от собственного пароля, но не от собственной политики доступа. Identity Provider сообщает, кто вошёл и какие атрибуты ему известны. Решение о том, что этому пользователю разрешено внутри приложения, обычно всё равно остаётся за Service Provider.