SAML

Стандарт SAML включает:

• набор XML-протокольных сообщений;
• набор описаний связей для передачи сообщений;
• ряд профилей, комбинирующих вышеперечисленные компоненты.

Ключевым примером применения SAML является организация единого входа (SSO, англ. single sign-on) через веб-браузер. В рамках одной зоны безопасности SSO реализуется относительно просто (например, с помощью cookie), однако внедрение SSO между доменами безопасности осложнено недостаточной совместимостью проприетарных решений. Профиль Web Browser SSO для SAML был стандартизирован с целью повышения межоперабельности^[1]. На практике SAML-SSO чаще всего применяется для аутентификации в облачном бизнес-программном обеспечении^[2].

Стандарт SAML определяет три роли: субъект, поставщик удостоверений и поставщик услуг. В основном сценарии субъект запрашивает доступ к сервису у поставщика услуг(SP), который обращается к поставщику удостоверений(IdP) за подтверждением аутентификации субъекта. Получив утверждение, он принимает решение о предоставлении доступа.

В центре SAML-утверждения находится субъект — пользователь в определённой зоне безопасности, относительно которого предоставляется утверждение. Хотя субъект — обычно человек, это не строго обязательно; термины «субъект» и «principal» могут использоваться как синонимы^[3].

Перед передачей утверждения от IdP к SP IdP может запросить у пользователя (principal) подтверждение личности — например, имя и пароль. SAML определяет структуру утверждения между участниками. Один IdP может обслуживать множество SP, и наоборот, SP может доверять различным независимым IdP^[4].

Способ аутентификации у поставщика удостоверений SAML не регламентирует: это может быть ввод логина/пароля, многофакторная аутентификация, служба каталогов (RADIUS, LDAP, Active Directory) и др^[5]. Некоторые крупные интернет-сервисы предоставляют функции удостоверяющих сервисов, использующихся и в SAML-взаимодействиях.

Технический комитет по сервисам безопасности в составе Организации по продвижению стандартов структурированной информации (OASIS), созданный в январе 2001 года, поставил целью разработку XML-стандарта для обмена данными аутентификации и авторизации^[6]. К февралю 2001 года комитету были переданы наработки:

• Security Services Markup Language (S2ML, Netegrity)
• AuthXML (Securant)
• XML Trust Assertion Service Specification (X-TASS, VeriSign)
• Information Technology Markup Language (ITML, Jamcracker)

В ноябре 2002 года OASIS объявила о принятии спецификации SAML 1.0 в качестве стандарта^[7].

Параллельно Альянс Liberty (Liberty Alliance), включавший ИТ-компании, некоммерческие и государственные организации, предложил расширение к SAML — Framework Liberty Identity Federation (ID-FF)^[8], сосредоточенное на кросс-доменных браузерных SSO и введении «круга доверия» (circle of trust), где каждый участник документирует используемые протоколы идентификации, методы аутентификации и связанные политики. Оценка этой информации другими участниками опирается на доверие кругу^[9].

Когда Альянс Liberty разрабатывал ID-FF, SSTC вела работу над обновлением SAML: в сентябре 2003 года появился стандарт SAML 1.1, а в том же году Liberty передала OASIS спецификацию ID-FF 1.2. Это сформировало основу для SAML 2.0, официально объявленного в марте 2005 года; в новой версии были объединены ID-FF, расширения Shibboleth и ранние варианты самого SAML. Большинство реализаций поддерживают SAML 2.0, часть — SAML 1.1 для совместимости. К 2008 году распространение SAML 2.0 стало нормой для госсектора, образования и бизнеса по всему миру^[9].

Стандарт SAML прошёл одно минорное и одно мажорное обновление с момента появления версии 1.0:

• SAML 1.0 принят OASIS в ноябре 2002 года;
• SAML 1.1 утверждён в сентябре 2003 года;
• SAML 2.0 принят в марте 2005 года.

Вклад Liberty Alliance в развитие — Identity Federation Framework (ID-FF), передан OASIS в сентябре 2003:

• ID-FF 1.1 — апрель 2003;
• ID-FF 1.2 — ноябрь 2003.

Версии SAML 1.0 и 1.1 сходны с незначительными изменениями^[10], однако SAML 2.0 несовместим с предыдущими версиями и содержит значительные отличия.

Между SAML 2.0 и ID-FF 1.2 также есть отличия: несмотря на общее происхождение, спецификации несовместимы^[9].

SAML базируется на следующих стандартах:

• Extensible Markup Language (XML): большинство обменов SAML использует стандартную XML-разметку.
• XML Schema (XSD): спецификация утверждений и протоколов SAML частично основана на схемах XML.
• XML Signature: обе версии (1.1 и 2.0) используют цифровые подписи на базе этого стандарта.
• XML Encryption: начиная с SAML 2.0 поддерживается шифрование идентификаторов, атрибутов и утверждений; в SAML 1.1 шифрование отсутствует. Известны серьёзные уязвимости в XML Encryption^[11].^[12]
• Hypertext Transfer Protocol (HTTP): основной транспортный протокол SAML.
• Simple Object Access Protocol (SOAP): SAML оперирует использованием SOAP (версии 1.1)^[13].

SAML определяет структуру утверждений, протоколов, bindings и профилей. Понятие «ядро SAML» (core) охватывает основные синтаксис и семантику утверждений и протоколов запроса/ответа. «Протокол SAML» регламентирует только содержание (what), но не способ передачи (how), который задаёт binding.

«SAML-binding» — это сопоставление элементов протокола SAML со стандартными транспортными механизмами; пример — передача внутри SOAP envelope поверх HTTP.

«Профиль SAML» определяет прикладной сценарий использования, соединяя утверждения, протоколы и bindings.

SAML-утверждение — это пакет удостоверяющей информации:

 <saml:Assertion ...>
   ..
 </saml:Assertion>

В упрощённом виде его можно прочесть так:

Утверждение A выпущено в момент времени t издателем R относительно субъекта S, при условии выполнения условий C.

Утверждения обычно переходят от IdP к SP и содержат сведения, необходимые SP для принятия решения о доступе. В SAML определены три типа утверждений:

1. Об аутентификации (authentication statements)
2. Об атрибутах (attribute statements)
3. О разрешении (authorization decision statements)

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

Утверждение об атрибуте сообщает, что субъект связан с определённым набором характеристик (атрибутов — пар «имя–значение»), используемых для принятия решений о доступе.

Утверждение об авторизации сообщает, что субъекту разрешено совершать действие A над ресурсом R при условии наличия доказательства E. Более сложные сценарии рекомендуется реализовывать с помощью XACML.

SAML-протокол определяет правила упаковки элементов (включая утверждения) в запросы/ответы, а также регламенты обработки сообщений. В общем случае это протокол типа запрос-ответ.

Ключевой тип запроса SAML — «запрос» (query): SP обращается к IdP по безопасному каналу (обычно через SOAP).

Существуют три типа SAML-запросов, соответствующие типам утверждений:

1. Запрос аутентификации (authentication query)
2. Запрос атрибута (attribute query)
3. Запрос авторизации (authorization decision query)

Ответ на запрос атрибута — это SAML-ответ с утверждением об атрибуте. Пример запроса/ответа приведён в статье SAML 2.0#SAML attribute query.

Более сложные протоколы появились только в SAML 2.0, где подробно определены:

• Протокол запроса/ответа по утверждению;
• Протокол запроса аутентификации;
• Протокол разрешения артефакта;
• Протокол управления идентификатором имени;
• Протокол единого выхода;
• Протокол сопоставления идентификаторов имён.

Binding SAML — это трансляция сообщения протокола SAML в формат или протокол передачи. Примером служит упаковка сообщения в SOAP envelope и последующая передача по HTTP.

SAML 1.1 определяет только binding через SOAP. HTTP POST, редирект и артефакт-варианты реализованы для Web Browser SSO — более полно их специфицирует SAML 2.0, где binding полностью отделён от профиля.

В SAML 2.0 binding реализован отдельной спецификацией:

• SOAP binding (SOAP 1.1);
• обратный SOAP (PAOS) binding;
• HTTP redirect binding (GET);
• HTTP POST binding;
• HTTP artifact binding;
• SAML URI binding.

Это обеспечивает гибкость — например, в Web Browser SSO профиль возможно до 12 комбинаций binding между SP и IdP.

Профиль SAML — это детализированный сценарий применения утверждений, протоколов и binding. Ключевой профиль — Web Browser SSO Profile.

В SAML 1.1 реализованы два подтипа этого профиля: Browser/Artifact и Browser/POST, различающиеся способом передачи утверждения (по ссылке или значением). Первый требует бэканального обмена по SOAP, все потоки начинаются с запроса к IdP. Расширения этой схемы разрабатывались, например, проектом Shibboleth.

В SAML 2.0 профиль Web Browser SSO существенно переработан: его flows начинаются с запроса к SP, что расширяет гибкость, но требует механизмов «обнаружения IdP». Новые профили SAML 2.0 включают:

• Профили SSO:
  • Web Browser SSO Profile
  • Enhanced Client or Proxy (ECP) Profile
  • Identity Provider Discovery Profile
  • Single Logout Profile
  • Name Identifier Management Profile
• Artifact Resolution Profile
• Assertion Query/Request Profile
• Name Identifier Mapping Profile
• SAML Attribute Profiles

Важные сторонние SAML-профили:

• OASIS Web Services Security (WSS)
• Liberty Alliance
• OASIS eXtensible Access Control Markup Language (XACML)

Спецификации SAML рекомендуют — и в некоторых случаях требуют — использование следующих механизмов:

• TLS версии 1.0 и выше для защиты транспорта,
• XML Signature и XML Encryption для защиты сообщений.

Конкретный выбор механизмов аутентификации, целостности и конфиденциальности оставляется на усмотрение разработчиков и внедряющих организаций.

Основной сценарий применения SAML — единовход через веб-браузер (Web Browser SSO). Пользователь при помощи браузера (user agent) запрашивает защищённый ресурс у SAML-провайдера услуг; тот направляет запрос на аутентификацию к поставщику удостоверений через пользователя. Этапы взаимодействия выглядят следующим образом (для SAML 2.0):

Схема работы единого входа (SSO) с помощью SAML через веб-браузер

1. Запрос ресурса на SP

пользователь через браузер запрашивает защищённый ресурс у SP, например:

https://sp.example.com/myresource

Если для пользователя уже существует валидный security context на SP, переходят к шагу 8.

2. Редирект на сервис SSO IdP

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

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request

Значение параметра SAMLRequest — сжатый и закодированный в Base64 элемент <samlp:AuthnRequest>.

3. Запрос SSO на IdP

браузер делает GET-запрос сервису SSO IdP по указанному URL, проверяет AuthnRequest и (при отсутствии security context) инициирует процесс идентификации пользователя.

4. Ответ с формой XHTML

сервис SSO IdP отправляет XHTML-форму:

 <form method="post" action="https://sp.example.com/SAML2/SSO/POST">
   <input type="hidden" name="SAMLResponse" value="response" />
   ...
   <input type="submit" value="Submit" />
 </form>

Значение SAMLResponse — base64-кодированный элемент <samlp:Response>.

5. POST на Assertion Consumer Service SP

браузер отправляет форму SP.

6. Редирект к ресурсу

SP обрабатывает данные, создаёт security context пользователя и перенаправляет его к запрошенному ресурсу.

7. Повторный запрос к целевому ресурсу на SP

https://sp.example.com/myresource

8. Ответ с ресурсом

SP возвращает защищённый ресурс.

В SAML 1.1 процесс начинается с обращения к inter-site transfer service IdP на шаге 3.

Во всех приведённых обменах используются фронт-канальные взаимодействия (через браузер), без прямых бэканальных коммуникаций между IdP и SP. Для более защищённых обменов применяется передача артефактов (by reference), требующая бэканального запроса по SOAP/SAML over HTTP. Использование SOAP допустимо, но не обязательно — каждый сценарий выбирает подходящий binding.