CC BY
63
Анализ возможностей языка SAML 2.0
О.Р. Лапонина, МГУ им. Ломоносова, ф-т ВМК, научный сотрудник, laponina@oit.cmc.msu.ru
Аннотация
Статья посвящена анализу способов аутентификации в распределенных системах. В данной работе рассмотрены возможности языка Security Assertion Markup Language (SAML) для решения актуальных проблем использования одной учетной записи для входа в информационные системы, установившие определенные соглашения между собой - так называемый Single Sign-On (SSO). Рассмотрена архитектура языка SAML, компоненты SAML, использование различных протоколов, таких как НТТР или SOAP, для передачи компонентов SAML. Описаны основные профили SSO: инициируемый сервис провайдером с использованием Redirect/POST команд протокола НТТР, инициируемый провайдером идентификации с использованием POST команды протокола НТТР, профиль усиленного прокси клиента, использующий протокол SOAP, а также профиль единого выхода. Рассмотрено использование SAML для установления соответствия между несколькими учетными записями одного и того же пользователя - так называемая федератив-ность.
Способы использования SAML
Веб Single Sign-On
При использовании многих ИТ-систем требуется регистрация пользователя. В результате этого пользователям приходится запоминать большое количество паролей, а системным администраторам необходимо управлять большим количеством учетных записей. Это часто приводит к снижению уровня информационной безопасности, поскольку пользователи решают проблему запоминания большого количества паролей путем использования одинаковых паролей во всех системах. При этом эти учетные записи могут создаваться в организациях, готовых заключить между собой соглашения о поддержки единой политики безопасности. Для минимизации усилий как пользователей, так и администраторов и повышения уровня информационной безопасности можно использовать, во-первых, технологию единого входа, которая позволяет нескольким системам доверять аутентификации, выполненной одной из систем, а, во-вторых, технологию создания федеративности, устанавливающую соответствие между несколькими учетными записями одного и того же пользователя.
Существует достаточно много стандартов и программных продуктов, реализующих эти подходы.
Обычно для реализации веб-SSO используются cookies для хранения информации в браузере о состоянии аутентификации пользователя, в результате чего повторная аутентификация не требуется каждый раз, когда пользователь получает доступ к системе через веб. Однако, так как cookies браузера не передаются между DNS доменами, информация о состоянии аутентификации, хранимая в cookies, из одного домена не доступна в другом домене. Поэтому необходима поддержка какого-либо механизма междоменного SSO для передачи информации о состоянии аутентификации между доменами. В гетерогенных средах необходим стандарт, которого бы придерживались все производители программных продуктов, реализующих междоменный SSO. Security Assertion Markup Language (SAML) предоставляет стандартные, независимые от производителя грамматику и протокол для передачи информации о пользователе от одного веб-сервера другому независимо от доменов DNS.
Предположим, что пользователь аутентифицировался на некотором веб-сайте, в результате чего для него была создана входная сессия (которая содержит контекст безопасности - security context). Затем он явно или прозрачно обращается к веб-сайту партнера. Будем предполагать, что между этими сайтами предварительно установлено соглашение о возможности доверять аутентификации пользователей, выполненной на первом веб-сайте. В этом случае первый сайт, на котором выполнена аутентификация, называется провайдером идентификации (Identity Provider - IdP), второй сайт - сервис провайдером (Service Provider - SP). IdP должен доказать SP, что пользователь аутентифицирован и имеет определенные атрибуты (например, «золотой партнер»). После этого пользователю не потребуется повторная аутентификация при доступе ко второму сайту. Данный сценарий называется как IdP-инициирующий веб-SSO сценарий.
Однако более часто встречается сценарий, в котором пользователь обращается к SP для получения доступа к ресурсам, к которым требуется аутентификация. При использовании SAML SP направляет пользователя к IdP для аутентификации. Данный сценарий называется SP-инициирующим веб-SSO. После успешной аутентификации IdP предоставляет утверждение, которое может использоваться SP для проверки прав доступа пользователя к защищенному ресурсу. SAML 2.0 поддерживает как IdP-инициирующий, так и SP-инициирующий сценарии.
Использование федеративной идентификации
Часто требуется обеспечить возможность пользователю, аутентифи-цировавшись в одном сервисе, получить доступ к другим сервисам. При
этом пользователи могут иметь индивидуальную локальную идентификацию на каждом из этих сервисов. Федеративность предоставляет способы согласовать общий идентификатор имени пользователя для подобных партнерских сервисов. Это позволяет разделять информацию о пользователе между этими сервисами. Говорят, что пользователь имеет федеративную идентификацию, когда партнеры устанавливают соглашения о том, как идентифицировать одного и того же пользователя. С административной точки зрения такой тип разделения может уменьшить стоимость управления идентификациями, так как многочисленным сервисам нет необходимости независимо собирать и поддерживать относящиеся к идентификации данные. Кроме того, обычно администраторы таких сервисов не устанавливают и не поддерживают вручную разделяемые идентификаторы; они скорее управляют тем, что может делать пользователь.
Существует много вопросов, которые должны быть рассмотрены, когда партнеры решают использовать федеративные идентификации, чтобы обеспечить общую политику безопасности:
• Должны ли существовать локальные идентификации пользователей
у провайдеров, к которым должны быть привязаны федеративные идентификации.
• Будут ли устанавливаться и завершаться федеративные идентифика-
торы пользователей динамически, или провайдеры будут использовать фиксированные федеративные идентификаторы.
• Необходимо ли явное согласие пользователя на установление феде-
ративной идентификации.
• Следует ли обмениваться идентификационными атрибутами о поль-
зователях.
• Может ли федеративная идентификация основываться на временных
идентификаторах, которые уничтожаются после завершения сессии пользователя.
• Можно ли обмениваться частной информацией, и должна ли такая
информация шифроваться.
Веб-сервисы
SAML предоставляет возможность использовать формат утверждений безопасности вне собственного протокола, определенного в стандарте SAML. Это дает возможность использовать утверждения SAML в других сервисах аутентификации и авторизации, таких как веб-сервисы, Грид, Cloud вычисления и т.п. Технический Комитет OASIS WS-Security определил профиль, описывающий использование утверждений SAML внутри WS-Security токенов безопасности (см [5]), предназначенных для обеспечения безопасности обмена SOAP сообщениями веб-сервисов. Преимущество состоит в том, что утверждения SAML
предоставляют стандартный подход к обмену информацией, включая атрибуты, которые не могут быть передана с использованием других форматов токенов WS-Security.
Архитектура SAML
Спецификации версии 2.0 являются дальнейшим развитием спецификаций SAML vl^. SAML vl^ описывает простой способ обмена идентификационными данными. Дальнейшее развитие этот подход получил в спецификациях Liberty ID-FF. Следующая версия 1.2 Liberty ID-FF была интегрирована со спецификацией SAML v2.
Рис. 2. Взаимное влияние различных стандартов, обеспечивающих SSO
Стандарт SAML v2.0 определяет основанный на XML каркас для обмена информацией, относящейся к безопасности. Информация о безопасности выражена в форме утверждений SAML, которым приложения, выполняющиеся в разных доменах безопасности, могут доверять (см [1]). Стандарт SAML определяет строгий синтаксис и правила для запроса, создания, взаимодействия и использования этих утверждений SAML.
OASIS SSTC разработал большое количество спецификаций, касающихся SAML 2.0, определяющих его использование в конкретных окружениях или его интеграцию с другими технологиями.
На рисунке показана взаимосвязь между базовыми понятиями SAML:
Profiles
Combinations of assertions, protocols, and bindings to support a defined use case
Authentication Context
Detailed data on types and strengths of authentication
Protocols
Requests and responses for obtaining assertions and doing identity management
Рис. З. Базовые компоненты SAML
Утверждения: SAML определяет синтаксис и семантику утверждений, относящихся к аутентификации, атрибутам и авторизационной информации. Определены следующие типы утверждений (см[2]):
- Аутентификационные утверждения создаются стороной, которая выполняла аутентификацию пользователя. Как минимум в них описываются способы, использованные для аутентификации пользователя, и время, когда аутентификация имела место.
- Утверждения, содержащие информацию об атрибутах содержат значения атрибутов субъекта (например, пользователь «John Doe» имеет статус карты «Gold»).
- Утверждения, содержащие информацию об авторизационных решениях определяют к каким ресурсам субъект имеет право доступа.
Протоколы: SAML определяет несколько протоколов типа запрос/ответ:
• Протокол запроса аутентификации определяет способы, которыми принципал (или агент, действующий от имени принципала) может запросить утверждения, содержащие аутентификационные данные и, возможно, атрибуты. SSO профиль веб-браузера использует данный протокол при перенаправлении пользователя от SP к IdP, когда ему необходимо установить контекст безопасности для принципала
• Протокол единого выхода определяет механизм, позволяющий одновременный выход из активных сессий, связанных с принципалом. Выход может непосредственно инициироваться пользователем или
на SP.
инициироваться IdP или SP в результате таймаута сессии, команды администратора и т.п.
• Протокол запроса и ответа утверждения определяет совокупность
элементов, которые могут содержаться в утверждениях SAML, посылаемых и получаемых участниками SAML.
• Протокол определения артефактов предоставляет механизм, с по-
мощью которого сообщения протоколов SAML могут передаваться в виде ссылки как небольшое, фиксированной длины значение, называемое артефактом. Получатель артефакта использует данный протокол для запроса всего сообщения.
• Протокол управления идентификаторами имен предоставляет
механизмы для обмена значением или форматом идентификатора имени принципала. Создатель запроса может быть либо сервис провайдер, либо идентификатор провайдер. Протокол также предоставляет механизм, позволяющий прервать связывание идентификаторов имени между SP и IdP.
Способы передачи определяют, как различные сообщения протоколов SAML могут передаваться поверх лежащих в основе транспортных протоколов. В SAML 2.0 определены следующие способы передачи:
• HTTP Redirect определяет, как сообщения протокола SAML могут
передаваться, используя НТТР Redirect сообщения (ответы с кодом статуса 302).
• HTTP POST определяет, как сообщения протокола SAML могут
передаваться с использованием команды НТТР POST.
• HTTP Artifact определяет, как артефакт передается от отправителя
сообщения к получателю сообщения, используя НТТР.
• SAML SOAP определяет, как сообщения протокола SAML переда-
ются внутри SOAP 1.1 сообщений, используя SOAP поверх НТТР.
• Reverse SOAP (PAOS) определяет обмен SOAP/HTTP сообщениями
в несколько стадий, который позволяет НТТР клиенту быть получателем SOAP. Используется в Расширенном Профиле Клиента и Прокси, чтобы предоставить возможность клиентам и прокси обнаружить IdP.
• SAML URI определяет способы получения существующих утвер-
ждений SAML с помощью разрешения (обнаружения) URI. Профили SAML определяют, какие утверждения, протоколы и способы передачи SAML используются в конкретных сценариях. Некоторые из этих сценариев рассмотрены более детально. В SAML 2.0 определены следующие Профили (см [3]):
• SSO профиль веб-браузера определяет, как элементы SAML ис-
пользуют Протокол Запроса Аутентификации и сообщения и утверждения ответа SAML для реализации SSO в стандартных веб-
браузерах. Он определяет, как сообщения используют возможности НТТР Redirect, POST и способы передачи артефактов.
• Профиль Enhanced Client and Proxy (ECP) определяет SSO про-
филь для специальных клиентов, которые могут использовать протокол SOAP.
• Профиль обнаружения провайдера идентификации определяет
механизм, позволяющий SP получить информацию о IdP пользователя.
• Профиль единого выхода определяет, как использовать протоколы
SOAP, HTTP Redirect, HTTP POST и HTTP артефакт для выполнения одновременного выхода из всех сессий.
• Профиль запроса и ответа утверждения определяет, как участники
SAML могут использовать протокол запроса и ответа SAML для получения утверждений SAML при синхронном способе передачи, таком как SOAP.
• Профиль получения артефакта определяет, как участники SAML
могут использовать протокол получения артефакта при синхронном способе доставки, таком как SOAP, для получения сообщения протокола, на которое ссылается артефакт.
• Профиль управления идентификатором имени определяет, как
протокол управления идентификатором имени может быть использован со способами передачи SOAP, HTTP Redirect, POST и артефакт.
• Профиль отображения идентификатора имени определяет, как
протокол отображения идентификатора имени использует синхронный способ передачи, такой как SOAP.
Metadata определяют описание конфигурационных данных (например, URLs конечных точек сервиса, ключи для проверки подписей).
Аутентификационный контекст описывает синтаксис различных механизмов аутентификации. Во многих случаях сервис провайдеру может быть необходимо иметь более детальную информацию, относящуюся к типу и способу аутентификации пользователя, выполненном провайдером идентификации. Данная информация передается в аутен-тификационном контексте (см [4]).
Основные профили и варианты использования
SAML определяет несколько профилей, описывающих использование сообщений протокола и утверждений SAML для решения конкретных задач. Рассмотрим более детально наиболее важные профили SAML и возможности использования федеративной идентификации.
SSO профиль веб-браузера
SSO профиль веб-браузера определяет, как использовать сообщения и способы передачи SAML для поддержки веб-SSO. Данный профиль предоставляет широкий диапазон возможностей, основное различие которых состоит в том, кто инициирует аутентификацию, SP и IdP, и как осуществляется взаимодействие между IdP и SP.
1с!Р-т№а1ес] вР-ШПМе«]
Рис. 4. Модели аутентификации
В ЫР-инициируемом сценарии пользователь сначала обращается к IdP, где он аутентифицируется, и затем переходит на SP. IdP создает утверждение, определяющее состояние аутентификации пользователя на №, перенаправляет браузер пользователя к SP, который обрабатывает утверждение и создает локальный контекст безопасности для пользователя. Такой подход используется в основных окружениях, но требует, чтобы IdP был сконфигурирован с внутренней ссылкой на SP. Иногда используется специальное связывающее поле, называемое RelayState, для координации сообщений и действий IdP и SP, например, позволяя на IdP (на котором был инициирован SSO) указать URL требуемого ресурса на SP.
Другим сценарием является SP-инициирующая модель веб-SSO. В этом сценарии пользователь обращается к ресурсу на SP. Предполагается, что пользователь еще не аутентифицирован, поэтому SP перенаправляет пользователя к IdP для выполнения аутентификации. IdP создает утверждение, доказывающее аутентификацию пользователя, и перенаправляет пользователя обратно к SP. SP анализирует полученное утверждение и определяет, предоставлять ли пользователю доступ к ресурсу.
Эта модель предполагает, что утверждения SAML будут пересылаться между IdP и SP в обе стороны. Для профиля веб-SSO в основном используются два сообщения SAML: сообщение запроса аутентификации посылается от SP к IdP, и сообщение ответа, содержащее утверждение SAML, посылается от IdP к SP.
В профилях SAML определяются способы использования нижележащих протоколов, с помощью которых пересылаются эти сообщения. В частности, сообщение Запроса Аутентификации может быть послано от SP к IdP, используя НТТР Redirect, HTTP POST или Артефакт. Сообщение Ответа может быть послано от IdP к SP, используя HTTP POST или артефакт. Для этих пар сообщений SAML допускает асимметрию в выборе используемого способа передачи. Это означает, что запрос может быть послан с использованием одного способа передачи, и ответ может быть возвращен с использованием другого. Решение о том, какой способ передачи используется, обычно определяется конфигурационными установками в системах IdP и SP. Такие факторы, как потенциальный размер сообщений, допускается ли передача идентификационной информации через браузер и т.п. должны рассматриваться при выборе способа передачи.
ЕСР профиль
Enhanced Client and Proxy (ECP) Профиль предназначен для следующих случаев использования SSO:
• Для клиентов, имеющих большие чем браузер возможности, что по-
зволяет им более активно участвовать в обнаружении IdP и потоке сообщений.
• При использовании прокси сервера, например, WAP шлюза, к кото-
рому обращается мобильное устройство, имеющий ограниченную функциональность.
• Когда другие способы доставки невозможны (например, клиент не
поддерживает Redirect, автоматическая пересылка формы невозможна без JavaScript или передача артефакта невозможна, потому что провайдер идентификации и сервис провайдер не могут взаимодействовать непосредственно.
Профиль единого выхода
После выполнения SSO разные сервис провайдеры разделяют единственный аутентификационный контекст. В этом случае необходимо иметь возможность одновременно завершить сессии на всех SP, участвующих в SSO.
Этот процесс называется Единым выходом, в результате которого выполняется выход из всех SPs, участвующих в SSO.
Запрос окончания сессии может быть создан любым участником сессии. Сообщения выхода могут передаваться либо в синхронном SOAP сообщении, передаваемом поверх НТТР, либо используя асинхронный НТТР Redirect, HTTP POST или артефакт способы доставки. Заметим, что операция выхода из браузера часто требует доступа к локальным аутентификационным cookies, хранимым в браузере пользователя. Таким образом, асинхронное связывание обычно обладает преимуществом при таких обменах, так как позволяет обойти каждого участника сессии для получения доступа к cookies в браузере. Однако пользователь может закрыть браузер, в результате чего не все аутентификационные cookies в браузере будут удалены.
Установление и управление федеративными идентификациями
Мы рассмотрели примеры, в которых внимание фокусировалось на обменах сообщениями, требуемыми для реализации решений веб-SSO. Теперь рассмотрим, как эти обмены сообщениями связаны с локальной и федеративной идентификациями отдельного участниками.
Определены механизмы, поддерживаемые SAML, для установления и управления федеративными идентификациями. Рассмотрены следующие возможности:
• Федеративность с помощью внешнего связывания акаунта: ус-
тановление федеративных идентификаций для пользователей и связывание этих идентификаций с локальными идентификациями пользователя может быть выполнено без использования протоколов и утверждений SAML. Это определяет способ федеративности, поддерживаемый SAML v1.
• Федеративность с помощью Постоянных Идентификаторов:
провайдер идентификатора связывает локальную идентификацию пользователя с идентификацией на SP, используя постоянное имя.
• Федеративность с помощью Временных Идентификаторов: вре-
менный идентификатор используется для объединения локальных идентификаций на IdP и SP на время жизни сессии пользователя.
• Федеративность с помощью Атрибутов Идентификации: атрибу-
ты принципала, определенные провайдером идентификатора, используются для связи с акаунтом, используемым на SP.
• Завершение Федеративности: завершение существующей федера-
тивности.
Использование атрибутов
В случае веб-SSO утверждение SAML, передаваемое от IdP к SP, может содержать атрибуты, описывающие пользователя. Возможность передавать атрибуты внутри утверждения является сильной стороной
SAML и может также комбинироваться с формами федеративности, описанными выше.
Самые типичные примеры использования:
7. Передача информации из профиля
Атрибуты могут использоваться для пересылки информации о профиле пользователя, предоставляемой SP. Данная информация может использоваться для персонализации сервисов на SP или даже для создания нового акаунта для пользователя на SP. Пользователь должен быть информирован о передачи информации из профиля и, если требуется, явно давать разрешение на такую пересылку.
8. Основа для авторизации
В этом случае атрибуты, предоставляемые в утверждении SAML от IdP, используются для доступа к конкретным сервисам на SP. SP и IdP необходимо предварительное соглашение (внешними способами) об именах и значениях атрибутов, включенных в утверждение SAML. Интересным использованием данного шаблона является возможность анонимности, что позволят находить определенному кругу людей различные классы сервисов: федеративность с использованием временных псевдонимов в комбинации с авторизацией на основе атрибутов.
Расширение и профилирование SAML
для использования в других окружениях
Компоненты SAML являются модульными и расширяемыми. Спецификация Утверждений и Протоколов SAML имеет раздел, описывающий возможности расширения. Спецификация Профилей SAML предоставляет руководство по созданию новых профилей и атрибутов профилей. Возможно определить новые способы передачи.
Как результат, SAML можно адаптировать к различным окружениям.
Литература
6. Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS Standard, 2008, с.51.
7. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 2005, с.86.
8. Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 2005, с.66.
9. Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, 2005, с.70.
10. Web Services Security UsernameToken Profile 1.0, OASIS Standard, 2004, с.14.
