Утверждение SAML

Утверждение SAML (англ. SAML assertion) — это структура данных в формате XML, формируемая и подписываемая поставщиком удостоверений (IdP) в рамках протокола Security Assertion Markup Language (SAML). Утверждение содержит заявления (statements) о субъекте (обычно пользователе), которые передаются поставщику услуг (SP) для принятия решения о предоставлении доступа к ресурсам или совершения иных действий. Утверждение является центральным элементом механизма единого входа (SSO) на основе SAML, обеспечивая передачу аутентификационной и атрибутивной информации между доверенными сторонами.

История и стандартизация

Протокол SAML, включая формат утверждений, разрабатывался организацией OASIS (Organization for the Advancement of Structured Information Standards). Первая версия стандарта (SAML 1.0) была принята в ноябре 2002 года. Версия SAML 1.1 вышла в сентябре 2003 года и получила широкое распространение в корпоративных и государственных информационных системах. Современная версия SAML 2.0, утверждённая в марте 2005 года, является отраслевым стандартом и используется в подавляющем большинстве реализаций. Она базируется на более ранних спецификациях Liberty Alliance и Shibboleth. Утверждения SAML 2.0 определяются в документе «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0».

Структура утверждения

Утверждение SAML представляет собой XML-документ с корневым элементом <Assertion>. Основные компоненты утверждения:

• Issuer (издатель) — элемент <Issuer>, содержащий уникальный идентификатор (обычно URL) поставщика удостоверений, сформировавшего утверждение.
• Signature (подпись) — элемент <Signature>, обеспечивающий целостность и аутентичность утверждения. Подпись может быть наложена на всё утверждение или на отдельные его части. Используются стандарты XML Signature (XMLDSig).
• Subject (субъект) — элемент <Subject>, идентифицирующий пользователя или иной субъект, о котором делаются заявления. Обычно содержит <NameID> — уникальный идентификатор субъекта (например, адрес электронной почты или постоянный идентификатор), а также необязательные элементы <SubjectConfirmation>, определяющие способ подтверждения связи субъекта с утверждением (например, по артефакту или по ключу носителя).
• Conditions (условия) — элемент <Conditions>, задающий ограничения на использование утверждения: время действия (NotBefore, NotOnOrAfter), аудиторию (AudienceRestriction) — список поставщиков услуг, для которых утверждение действительно, и другие условия.
• Statements (заявления) — один или несколько элементов, содержащих собственно утверждения. В SAML 2.0 определены три основных типа заявлений:
• Authentication Statement (<AuthnStatement>) — содержит информацию о событии аутентификации: время, метод аутентификации (например, пароль, сертификат, биометрия), а также идентификатор сессии.
• Attribute Statement (<AttributeStatement>) — содержит набор атрибутов субъекта, таких как ФИО, роль, группа, адрес электронной почты, номер телефона и другие. Каждый атрибут представлен элементом <Attribute> с именем и значением (или несколькими значениями).
• Authorization Decision Statement (<AuthzDecisionStatement>) — содержит решение о разрешении или запрете выполнения субъектом определённого действия над ресурсом. В SAML 2.0 этот тип заявления используется реже, так как управление доступом чаще реализуется на стороне поставщика услуг на основе атрибутов.
• Advice (совет) — необязательный элемент, содержащий дополнительные сведения, не влияющие на основное решение (например, ссылки на другие утверждения или сертификаты).

Типы утверждений

В зависимости от содержащихся заявлений различают три основных типа утверждений SAML:

1. Утверждение аутентификации (Authentication Assertion) — содержит только AuthnStatement. Используется для подтверждения факта успешной аутентификации субъекта в определённый момент времени определённым способом. Поставщик услуг на основе этого утверждения может создать локальную сессию для пользователя.
2. Утверждение атрибутов (Attribute Assertion) — содержит только AttributeStatement. Передаёт набор атрибутов субъекта без информации о процессе аутентификации. Часто используется в сценариях, где аутентификация уже выполнена другим способом.
3. Утверждение решения авторизации (Authorization Decision Assertion) — содержит только AuthzDecisionStatement. Информирует поставщика услуг о том, разрешено ли субъекту выполнить конкретное действие над конкретным ресурсом. В современных реализациях SAML 2.0 используется редко; управление доступом обычно делегируется поставщику услуг.

На практике одно утверждение может содержать несколько заявлений разных типов. Например, утверждение, передаваемое при едином входе, часто включает как AuthnStatement, так и AttributeStatement.

Формат и передача

Утверждение SAML может передаваться от поставщика удостоверений к поставщику услуг несколькими способами, определёнными в протоколе SAML:

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

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

Утверждения SAML являются критически важными для безопасности информационных систем. Основные меры защиты:

• Цифровая подпись — обязательное требование для утверждений, передаваемых по незащищённым каналам (например, через браузер). Подпись гарантирует, что утверждение не было изменено после создания и что оно исходит от доверенного поставщика удостоверений.
• Шифрование — может применяться для защиты конфиденциальных атрибутов (например, персональных данных) внутри утверждения. Шифрование выполняется с использованием открытого ключа поставщика услуг.
• Условия использования — ограничение времени действия (NotBefore, NotOnOrAfter) и аудитории (AudienceRestriction) предотвращают повторное использование утверждения за пределами допустимого контекста.
• Подтверждение субъекта — элемент <SubjectConfirmation> определяет, как поставщик услуг может убедиться, что утверждение относится именно к тому субъекту, который его предъявляет. Наиболее распространённый метод — bearer (предъявитель), при котором любое лицо, владеющее утверждением, считается субъектом. Этот метод требует использования защищённых каналов (HTTPS) для предотвращения перехвата.

Применение

Утверждения SAML широко применяются в корпоративных и государственных информационных системах для реализации:

• Единого входа (SSO) — пользователь аутентифицируется один раз у поставщика удостоверений и получает утверждение, которое затем предъявляет различным поставщикам услуг без повторного ввода учётных данных.
• Федеративной идентификации — объединение учётных записей пользователей между различными организациями (например, университетами, государственными учреждениями, коммерческими компаниями) на основе доверительных отношений.
• Управления доступом на основе атрибутов (ABAC) — поставщик услуг принимает решение о предоставлении доступа на основе атрибутов, переданных в утверждении (например, роль, отдел, уровень допуска).
• Обмена данными между системами — передача информации о пользователе (атрибутов) между приложениями без необходимости синхронизации баз данных.

Пример упрощённого утверждения

``xml <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_1234567890" IssueInstant="2023-10-27T10:00:00Z"> <saml:Issuer>https://idp.example.com</saml:Issuer>; <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>; <saml:Subject> <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user@example.com</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/> </saml:Subject> <saml:Conditions NotBefore="2023-10-27T09:55:00Z" NotOnOrAfter="2023-10-27T10:05:00Z"> <saml:AudienceRestriction> <saml:Audience>https://sp.example.com</saml:Audience>; </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2023-10-27T09:59:00Z" SessionIndex="_session123"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="displayName"> <saml:AttributeValue>Иван Иванов</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="role"> <saml:AttributeValue>admin</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> ``

Критика и ограничения

• Сложность реализации — протокол SAML, включая формат утверждений, имеет большое количество опций и конфигураций, что может приводить к ошибкам при настройке и уязвимостям (например, неправильная проверка подписи или аудитории).
• Зависимость от XML — использование XML делает утверждения громоздкими и менее производительными по сравнению с более современными форматами, такими как JSON (используется в протоколе OpenID Connect).
• Отсутствие встроенной поддержки современных сценариев — протокол SAML изначально ориентирован на веб-браузеры и не предоставляет удобных механизмов для мобильных приложений, одностраничных приложений (SPA) или сервер-серверных взаимодействий без участия браузера.
• Управление ключами и сертификатами — для работы с утверждениями требуется сложная инфраструктура управления сертификатами и ключами подписи/шифрования, что увеличивает эксплуатационные расходы.

Источники

• OASIS. «Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0». OASIS Standard, 2005.
• OASIS. «Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0». OASIS Standard, 2005.
• Ragouzis, N. et al. «Security Assertion Markup Language (SAML) V2.0 Technical Overview». OASIS Committee Draft, 2008.
• Cantor, S. et al. «SAML V2.0 Implementation Profile». OASIS Committee Specification, 2010.
• Maler, E., Mishra, P. «Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)». OASIS Standard, 2003.