SAML

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

История

Разработка SAML началась в 2001 году в рамках технического комитета OASIS Security Services (SAML). Первая версия стандарта, SAML 1.0, была утверждена в ноябре 2002 года. Она определяла базовые протоколы и форматы утверждений, но имела ограниченную поддержку и сложности в реализации.

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

В последующие годы стандарт развивался через выпуск дополнительных профилей и исправлений (errata). Актуальная версия спецификации — SAML V2.0 Errata Composite (2010 год с последующими обновлениями). Попытки создания версии 3.0 не привели к утверждению нового стандарта; вместо этого развитие идёт через публикацию отдельных профилей и расширений.

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

Архитектура SAML основана на трёх основных ролях: субъект (обычно пользователь), поставщик удостоверений (IdP) и поставщик услуг (SP).

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

Ключевым элементом SAML является утверждение (assertion) — XML-документ, содержащий информацию о субъекте. Существует три основных типа утверждений:

1. Утверждение аутентификации (Authentication Assertion) — подтверждает, что субъект был аутентифицирован определённым способом в определённое время.
2. Утверждение атрибутов (Attribute Assertion) — содержит дополнительные атрибуты субъекта (например, роль, email, отдел).
3. Утверждение авторизации (Authorization Decision Assertion) — содержит решение о том, разрешено ли субъекту выполнять определённое действие над ресурсом.

Утверждения могут быть подписаны цифровой подписью для обеспечения целостности и аутентичности, а также зашифрованы для конфиденциальности.

Протоколы и привязки

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

• SAML AuthnRequest/Response — основной протокол для запроса и получения утверждения аутентификации. SP инициирует запрос, перенаправляя пользователя на IdP. После аутентификации IdP возвращает ответ, содержащий утверждение.
• SAML Single Logout (SLO) — протокол для одновременного завершения сеансов пользователя на всех поставщиках услуг, входящих в федерацию.
• SAML Artifact Resolution — протокол, при котором утверждение не передаётся напрямую через браузер, а передаётся ссылка (артефакт), по которой SP запрашивает утверждение у IdP по прямому каналу.

Для передачи сообщений SAML используются различные привязки (bindings) к транспортным протоколам:

• HTTP Redirect Binding — сообщение SAML кодируется в URL-параметре HTTP-перенаправления (обычно используется для AuthnRequest).
• HTTP POST Binding — сообщение SAML передаётся в скрытом поле HTML-формы, которая автоматически отправляется (обычно используется для Response).
• HTTP Artifact Binding — передаётся артефакт (короткая ссылка), а само утверждение запрашивается по прямому каналу SOAP.
• SOAP Binding — сообщения SAML передаются непосредственно по протоколу SOAP (используется для сервер-серверных взаимодействий, например, для SLO).

Профили

Профили SAML описывают конкретные сценарии использования комбинаций утверждений, протоколов и привязок. Наиболее известные профили:

• Web Browser SSO Profile — самый распространённый профиль, обеспечивающий единый вход для пользователя через веб-браузер. Включает в себя как вариант с инициацией от SP (SP-initiated SSO), так и от IdP (IdP-initiated SSO).
• Single Logout Profile — профиль для реализации единого выхода.
• Identity Provider Discovery Profile — профиль для определения, какой IdP должен использоваться для аутентификации пользователя в федерации с несколькими IdP.
• Enhanced Client or Proxy (ECP) Profile — профиль для небраузерных клиентов (например, мобильных приложений или толстых клиентов).

Применение

SAML широко применяется в корпоративных информационных системах и облачных сервисах для организации единого входа и федеративного управления удостоверениями.

• Корпоративные порталы и приложения — сотрудники проходят аутентификацию один раз в корпоративном IdP (например, на базе Microsoft Active Directory Federation Services, Keycloak, или решениях от российских вендоров) и получают доступ к внутренним веб-приложениям, системам документооборота, CRM и ERP.
• Облачные сервисы — многие облачные провайдеры (SaaS-решения) поддерживают SAML 2.0 для интеграции с корпоративными системами управления удостоверениями. Пользователь может использовать свои корпоративные учётные данные для входа в облачные приложения.
• Государственные и образовательные системы — стандарт используется в федеративных системах для доступа к государственным услугам и образовательным ресурсам. Например, в США распространена федерация InCommon для высших учебных заведений. В России механизмы, схожие с SAML, применяются в некоторых государственных информационных системах, хотя чаще используется ГОСТ Р 58264 (на основе SAML 2.0) или проприетарные решения.
• Системы управления доступом к API — SAML может использоваться для аутентификации и авторизации при доступе к веб-сервисам и API, хотя в этой области более распространён протокол OAuth 2.0.

Безопасность

SAML 2.0 предусматривает ряд механизмов для обеспечения безопасности:

• Цифровая подпись — утверждения и запросы могут быть подписаны с использованием XML Signature. Это гарантирует, что сообщение не было изменено в пути и что оно исходит от доверенной стороны.
• Шифрование — утверждения могут быть зашифрованы с использованием XML Encryption. Это защищает конфиденциальные данные (например, атрибуты пользователя) от перехвата.
• Защита от повторного воспроизведения — в сообщения SAML включаются временные метки и идентификаторы, что позволяет SP обнаруживать повторную отправку перехваченных сообщений.
• Требование использования HTTPS — для передачи сообщений через браузер рекомендуется использовать защищённое соединение HTTPS, чтобы предотвратить перехват и подмену данных на транспортном уровне.

Несмотря на наличие механизмов защиты, неправильная реализация SAML может приводить к уязвимостям. Наиболее известные проблемы связаны с некорректной проверкой цифровых подписей (например, атака XML Signature Wrapping), неправильной обработкой XML-документов (атаки XXE) и недостаточной проверкой идентификаторов получателей (Audience Restriction).

Критика и альтернативы

SAML 2.0 подвергается критике за сложность реализации и избыточность спецификации. XML-формат утверждений и протоколов является громоздким по сравнению с более современными форматами, такими как JSON. Это увеличивает нагрузку на вычислительные ресурсы и усложняет отладку.

Основными альтернативами SAML являются:

• OAuth 2.0 — протокол авторизации, ориентированный на делегирование доступа к ресурсам. Часто используется в паре с OpenID Connect (OIDC), который добавляет уровень аутентификации. OAuth 2.0 и OIDC проще в реализации, используют JSON и REST, и стали стандартом для современных веб-приложений и мобильных приложений.
• WS-Federation — протокол от Microsoft, часть более широкой спецификации WS-*. Используется в продуктах Microsoft (Active Directory Federation Services). Постепенно уступает место OIDC.
• Shibboleth — реализация SAML, широко используемая в академической среде. Хотя сам Shibboleth основан на SAML, он часто рассматривается как отдельная экосистема.

В настоящее время SAML остаётся широко распространённым в корпоративном и государственном секторах, особенно в legacy-системах и федерациях, построенных до массового внедрения OIDC. Однако для новых проектов всё чаще выбирают OAuth 2.0 и OpenID Connect как более лёгкие и гибкие протоколы.

Источники

• OASIS Standard. «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0». March 2005.
• OASIS Standard. «SAML V2.0 Errata Composite». 2010.
• Specification: «SAML V2.0 Profiles».
• Specification: «SAML V2.0 Bindings».
• Specification: «SAML V2.0 Security Considerations».
• RFC 7522 — Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants.
• ГОСТ Р 58264-2018 «Информационная технология. Биометрия. Протоколы взаимодействия для систем аутентификации на основе биометрических данных. Часть 1. Протоколы на основе SAML».