SAML 2.0

SAML 2.0 (Security Assertion Markup Language 2.0) — это открытый стандарт на основе XML для обмена данными аутентификации и авторизации между сторонами, в частности между поставщиком удостоверений (Identity Provider, IdP) и поставщиком услуг (Service Provider, SP). Стандарт позволяет реализовать механизм единого входа (Single Sign-On, SSO), при котором пользователь проходит аутентификацию один раз у поставщика удостоверений, после чего получает доступ к нескольким независимым приложениям или сервисам без повторного ввода учётных данных. SAML 2.0 является преемником более ранних версий SAML 1.0 и 1.1 и на сегодняшний день остаётся одним из наиболее распространённых протоколов федеративного управления доступом в корпоративной и государственной среде.

История и развитие

Разработка SAML началась в 2001 году под эгидой организации OASIS (Organization for the Advancement of Structured Information Standards). Первая версия — SAML 1.0 — была утверждена в ноябре 2002 года. Она заложила базовые принципы обмена утверждениями (assertions) о пользователе, но имела ограниченную поддержку сценариев единого выхода и интероперабельности между различными реализациями.

В сентябре 2003 года вышла версия SAML 1.1, которая устранила ряд технических недочётов и стала основой для ранних внедрений SSO в корпоративных сетях. Однако настоящим прорывом стала версия SAML 2.0, опубликованная в марте 2005 года. Она объединила и расширила возможности не только предыдущих версий SAML, но и других смежных спецификаций, таких как Liberty Alliance Identity Federation Framework (ID-FF) и Shibboleth. В результате SAML 2.0 получил более гибкую модель доверия, поддержку различных протоколов связывания (bindings) и улучшенную совместимость с веб-технологиями.

С момента публикации SAML 2.0 не претерпел кардинальных изменений, однако OASIS выпускал уточняющие и дополняющие спецификации (профили), например, для мобильных устройств или для использования в сочетании с REST-архитектурами. Стандарт остаётся стабильным и широко поддерживается в программных продуктах, включая Microsoft Active Directory Federation Services (AD FS), Okta, Keycloak, ADFS, а также в облачных платформах Google Cloud и Amazon Web Services.

Архитектура и компоненты

Основные участники

Взаимодействие в рамках SAML 2.0 строится вокруг трёх ключевых ролей:

Поставщик удостоверений (Identity Provider, IdP) — сторона, которая отвечает за аутентификацию пользователя и выдачу утверждений (assertions) о его личности и атрибутах. IdP хранит учётные записи пользователей и может быть реализован, например, как сервер Active Directory или облачный сервис.
Поставщик услуг (Service Provider, SP) — сторона, предоставляющая пользователю доступ к приложению или ресурсу. SP доверяет утверждениям, полученным от IdP, и на их основе принимает решение о предоставлении доступа.
Пользователь (Principal) — субъект, который запрашивает доступ к ресурсу SP и проходит аутентификацию у IdP. Обычно пользователь взаимодействует с обеими сторонами через веб-браузер.

Утверждения (Assertions)

Центральным элементом SAML 2.0 является утверждение — XML-документ, подписанный цифровой подписью IdP. Утверждения могут быть трёх типов:

Аутентификационные (Authentication Assertions) — подтверждают, что пользователь успешно прошёл аутентификацию в определённый момент времени и определённым методом (например, по паролю или с помощью сертификата).
Атрибутивные (Attribute Assertions) — содержат набор атрибутов пользователя, таких как имя, электронная почта, роль, членство в группах.
Авторизационные (Authorization Decision Assertions) — указывают, разрешено ли пользователю выполнять определённое действие над ресурсом (например, чтение или запись). Этот тип используется реже, так как современные системы обычно принимают решения об авторизации на стороне SP на основе атрибутов.

Утверждения подписываются с использованием стандартов XML Signature (XMLDSig) для обеспечения целостности и аутентичности. Дополнительно может применяться шифрование отдельных элементов или всего утверждения с помощью XML Encryption.

Протоколы и связывания (Bindings)

SAML 2.0 определяет несколько способов передачи сообщений между IdP и SP. Наиболее распространённые:

HTTP Redirect Binding — используется для перенаправления пользователя с SP на IdP (или обратно) через HTTP-редирект с параметрами запроса. Обычно применяется для инициирования процесса аутентификации.
HTTP POST Binding — сообщения передаются через HTML-формы, которые автоматически отправляются браузером. Позволяет передавать большие объёмы данных (например, подписанные утверждения) и используется для передачи ответа от IdP обратно на SP.
Artifact Binding — вместо передачи полного утверждения через браузер передаётся короткий идентификатор (артефакт), который SP затем использует для прямого запроса к IdP по защищённому каналу (SOAP). Этот метод снижает нагрузку на браузер, но требует дополнительного сетевого обмена.
SOAP Binding — прямое взаимодействие между SP и IdP по протоколу SOAP, без участия браузера. Используется для обмена метаданными или в сценариях, не связанных с веб-браузером.

Метаданные

Для установления доверительных отношений между IdP и SP используется обмен метаданными — XML-документами, которые описывают конфигурацию каждой стороны: URL-адреса конечных точек, поддерживаемые связывания, сертификаты для проверки подписей и шифрования. Метаданные могут быть подписаны для предотвращения подмены. Обычно администраторы вручную обмениваются файлами метаданных или используют доверенный реестр.

Типовой сценарий работы (SSO)

Процесс единого входа с использованием SAML 2.0 в упрощённом виде выглядит следующим образом:

Пользователь пытается получить доступ к защищённому ресурсу на SP (например, к корпоративной CRM).
SP не обнаруживает активной сессии пользователя и генерирует запрос аутентификации (SAML Authentication Request). Запрос может содержать идентификатор SP, желаемый метод аутентификации и URL для обратного ответа (Assertion Consumer Service URL).
SP перенаправляет пользователя на IdP (обычно через HTTP Redirect или HTTP POST).
IdP проверяет, аутентифицирован ли пользователь в текущей сессии. Если нет — IdP запрашивает у пользователя учётные данные (логин и пароль, сертификат, одноразовый код и т.д.).
После успешной аутентификации IdP формирует утверждение (SAML Assertion), подписывает его и отправляет обратно на SP через браузер пользователя (обычно через HTTP POST).
SP получает утверждение, проверяет цифровую подпись, извлекает идентификатор пользователя и атрибуты, после чего создаёт локальную сессию для пользователя.
Пользователь получает доступ к запрошенному ресурсу. При последующих обращениях к другим SP, которые доверяют тому же IdP, процесс повторяется, но шаг 4 (повторный ввод пароля) не требуется, если сессия на IdP активна.

Профили SAML 2.0

Спецификация SAML 2.0 определяет несколько профилей — комбинаций утверждений, протоколов и связываний для конкретных сценариев:

Web Browser SSO Profile — основной профиль для реализации единого входа через веб-браузер. Описанный выше сценарий соответствует этому профилю.
Single Logout Profile — позволяет завершить сессии пользователя одновременно на IdP и на всех SP, которые участвовали в сессии. Реализуется через отправку сообщений о выходе (LogoutRequest и LogoutResponse).
Identity Provider Discovery Profile — используется в сценариях, где пользователь может выбирать IdP из нескольких (например, в федерациях). Помогает определить, к какому IdP направить пользователя.
Artifact Resolution Profile — применяется при использовании Artifact Binding для получения полного утверждения по артефакту.
Attribute Query Profile — позволяет SP запрашивать у IdP дополнительные атрибуты пользователя после завершения аутентификации, используя SOAP-запрос.

Преимущества и недостатки

Преимущества

Зрелость и стабильность. SAML 2.0 существует с 2005 года, имеет обширную документацию и множество проверенных реализаций.
Безопасность. Стандарт поддерживает цифровые подписи и шифрование, что защищает утверждения от подделки и перехвата.
Федеративность. Позволяет организовать доверительные отношения между организациями без необходимости синхронизации учётных записей.
Широкая поддержка. Почти все корпоративные системы управления доступом и облачные сервисы поддерживают SAML 2.0.

Недостатки

Сложность реализации. XML-формат утверждений и протоколов громоздок, а настройка взаимодействия между IdP и SP требует ручного обмена метаданными и сертификатами.
Зависимость от браузера. Большинство профилей SAML 2.0 предполагают перенаправление через браузер, что неудобно для мобильных приложений или API-интеграций без пользовательского интерфейса.
Отсутствие встроенной поддержки современных методов аутентификации. Стандарт изначально не учитывал биометрию, многофакторную аутентификацию (MFA) в явном виде, хотя современные реализации могут добавлять MFA на стороне IdP.
Медленная эволюция. Новые протоколы, такие как OpenID Connect (OIDC), предлагают более лёгкую интеграцию на основе JSON и REST, что делает их предпочтительными для современных веб-приложений и мобильных платформ.

Сравнение с альтернативами

SAML 2.0 vs OpenID Connect (OIDC)

OpenID Connect, построенный на основе OAuth 2.0, является более современным и простым протоколом. Основные отличия:

Формат данных. SAML использует XML, OIDC — JSON, что делает OIDC более компактным и удобным для веб- и мобильных приложений.
Архитектура. OIDC изначально ориентирован на API и REST, SAML — на браузерные сценарии.
Простота. OIDC требует меньше настроек и ручного обмена метаданными, поддерживает динамическую регистрацию клиентов.
Распространение. OIDC доминирует в сфере потребительских интернет-сервисов (Google, Facebook), в то время как SAML сохраняет позиции в корпоративном и государственном секторах.

SAML 2.0 vs WS-Federation

WS-Federation — ещё один протокол федерации, разработанный Microsoft. Он также использует XML и поддерживает SSO, но тесно связан с платформой .NET и Windows Identity Foundation. SAML 2.0 является более универсальным и независимым от вендора.

Применение в России

В Российской Федерации SAML 2.0 используется в корпоративных информационных системах, особенно в крупных государственных и коммерческих организациях, где требуется централизованное управление доступом к множеству приложений. Например, стандарт применяется в системах электронного документооборота, порталах государственных услуг (в части интеграции с ведомственными системами), а также в образовательных федерациях (например, в проекте «Современная цифровая образовательная среда»). Однако в последние годы наблюдается тенденция к переходу на более лёгкие протоколы, такие как OpenID Connect, особенно в новых разработках и облачных сервисах.

Критика

Основные критические замечания в адрес SAML 2.0 связаны с его избыточной сложностью и громоздкостью. XML-утверждения могут достигать десятков килобайт, что увеличивает время передачи и обработки. Кроме того, процесс настройки федерации требует квалифицированных администраторов и часто сопровождается ошибками при ручном обмене метаданными. Некоторые эксперты также отмечают, что стандарт недостаточно гибок для сценариев с динамической регистрацией поставщиков услуг, что ограничивает его применение в открытых экосистемах.

Источники

OASIS. «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0». March 2005.
OASIS. «SAML V2.0 Technical Overview». March 2008.
Ragouzis, N. et al. «Security Assertion Markup Language (SAML) V2.0: Technical Overview». OASIS Committee Draft, 2008.
Фонд «Свободное программное обеспечение». Документация по проекту Shibboleth.
Microsoft. «Active Directory Federation Services (AD FS) Technical Reference».
OpenID Foundation. «OpenID Connect Core 1.0». 2014.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →