Язык разметки утверждений безопасности

редактировать

Формат и протокол на основе XML для обмена данными аутентификации и авторизации между сторонами

Язык разметки утверждений безопасности ( SAML, произносится SAM-el) - это открытый стандарт для обмена данными аутентификации и авторизации между сторонами, в частности, между поставщик удостоверений и поставщик услуг. SAML - это язык разметки на основе XML для утверждений безопасности (утверждений, которые поставщики услуг используют для принятия решений по управлению доступом). SAML - это также:

набор протокольных сообщений на основе XML
набор привязок протокольных сообщений
набор профилей (использующих все вышеперечисленное)

важное применение случай, если адрес SAML - это веб-браузер система единого входа (SSO). Единый вход в систему относительно легко выполнить в пределах домена безопасности (например, с использованием файлов cookie ), но распространение единого входа на домены безопасности сложнее и привело к распространению несовместимых проприетарных технологий. Профиль SSO веб-браузера SAML был задан и стандартизирован для обеспечения взаимодействия.

Содержание

1 Обзор
2 История
3 Версии
4 Дизайн
- 4.1 Утверждения
- 4.2 Протоколы
- 4.3 Привязки
- 4.4 Профили
- 4.5 Безопасность
5 Использование
6 См. Также
7 Ссылки
8 Внешние ссылки

Обзор

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

В основе утверждения SAML лежит субъект (участник в контексте определенного домена безопасности), о котором что-то утверждается. Субъект обычно (но не обязательно) человек. Как и в «Техническом обзоре SAML V2.0», термины «субъект» и «принципал» в этом документе взаимозаменяемы.

Перед доставкой субъектного утверждения поставщику услуг IdP может запросить некоторую информацию от принципала, например имя пользователя и пароль, для аутентификации принципала. SAML определяет содержание утверждения, которое передается от IdP к SP. В SAML один поставщик удостоверений может предоставлять утверждения SAML многим поставщикам услуг. Точно так же один SP может полагаться на утверждения многих независимых IdP и доверять им.

SAML не определяет метод аутентификации у поставщика удостоверений. IdP может использовать имя пользователя и пароль или какую-либо другую форму аутентификации, включая многофакторную аутентификацию. Служба каталогов, такая как RADIUS, LDAP или Active Directory, которая позволяет пользователям входить в систему с именем пользователя и паролем, является типичным источником токенов аутентификации в поставщик удостоверений. Популярные службы социальных сетей в Интернете также предоставляют службы идентификации, которые теоретически могут использоваться для поддержки обмена SAML.

История

История SAML (2002–2005)

OASIS Технический комитет служб безопасности (SSTC), который впервые встретился в январе 2001 года, был учрежден «определить структуру XML для обмена информацией аутентификации и авторизации». С этой целью в течение первых двух месяцев этого года в SSTC была передана следующая интеллектуальная собственность:

Язык разметки служб безопасности (S2ML) от Netegrity
AuthXML от Securant
XML Спецификация службы утверждения доверия (X-TASS) от VeriSign
Язык разметки информационных технологий (ITML) от Jamcracker

Основываясь на этих первоначальных вкладах, в ноябре 2002 года OASIS анонсировала язык разметки утверждений безопасности (SAML) V1. 0 в качестве стандарта OASIS.

Между тем, Liberty Alliance, большой консорциум компаний, некоммерческих и государственных организаций, предложил расширение стандарта SAML под названием Liberty Identity Federation Фреймворк (ID-FF). Как и его предшественник SAML, Liberty ID-FF предлагала стандартизированную междоменную веб-платформу единого входа. Кроме того, Liberty описала круг доверия, в котором каждому участвующему домену доверяют точную документацию процессов, используемых для идентификации пользователя, типа используемой системы аутентификации и любых политик, связанных с полученными учетными данными аутентификации. Другие члены круга доверия могут затем изучить эти политики, чтобы определить, следует ли доверять такой информации.

Пока Liberty разрабатывала ID-FF, SSTC начала работу над незначительным обновлением до стандарта SAML. Получившаяся в результате спецификация SAML V1.1 была ратифицирована SSTC в сентябре 2003 года. Затем, в ноябре того же года, Liberty внесла ID-FF 1.2 в OASIS, тем самым посеяв семена для следующей основной версии SAML. В марте 2005 г. SAML V2.0 был объявлен стандартом OASIS. SAML V2.0 представляет собой конвергенцию Liberty ID-FF и проприетарных расширений, предоставленных проектом Shibboleth, а также ранних версий самого SAML. Большинство реализаций SAML поддерживают V2.0, в то время как многие по-прежнему поддерживают V1.1 для обратной совместимости. К январю 2008 года развертывание SAML V2.0 стало обычным явлением в правительстве, высших учебных заведениях и коммерческих предприятиях по всему миру.

Версии

SAML претерпел одну незначительную и одну основную редакцию по сравнению с версией V1.0.

SAML 1.0 был принят в качестве стандарта OASIS в ноябре 2002 г.
SAML 1.1 был ратифицирован в качестве стандарта OASIS в сентябре 2003 г.
SAML 2.0 стал стандартом OASIS в марте 2005 г.

Liberty Alliance внесла свою Identity Federation Framework (ID-FF) в OASIS SSTC в сентябре 2003 г.:

ID-FF 1.1 был выпущен в апреле 2003 г.
ID-FF 1.2 был завершен в ноябре 2003 г.

Версии 1.0 и 1.1 SAML похожи, хотя и существуют небольшие различия. Однако различия между SAML 2.0 и SAML 1.1 существенны. Хотя оба стандарта относятся к одному и тому же сценарию использования, SAML 2.0 несовместим со своим предшественником.

Хотя ID-FF 1.2 был внесен в OASIS в качестве основы SAML 2.0, между SAML 2.0 и ID-FF 1.2 есть некоторые важные различия. В частности, две спецификации, несмотря на их общие корни, несовместимы.

Дизайн

SAML построен на ряде существующих стандартов:

Extensible Markup Language (XML): большинство обменов SAML выражаются на стандартизированном диалекте XML, который является корнем для имя SAML (язык разметки утверждений безопасности).
Схема XML (XSD): утверждения и протоколы SAML указываются (частично) с использованием схемы XML.
Подпись XML : Оба SAML 1.1 и SAML 2.0 используют цифровые подписи (на основе стандарта подписи XML) для аутентификации и целостности сообщений.
Шифрование XML : с помощью шифрования XML SAML 2.0 предоставляет элементы для зашифрованного имени идентификаторы, зашифрованные атрибуты и зашифрованные утверждения (SAML 1.1 не имеет возможностей шифрования). Сообщается, что шифрование XML вызывает серьезные проблемы с безопасностью.
Протокол передачи гипертекста (HTTP): SAML в значительной степени полагается на HTTP в качестве протокола связи.
SOAP : SAML определяет использование SOAP, в частности SOAP 1.1.

SAML определяет утверждения и протоколы, привязки и профили на основе XML. Термин «ядро SAML» относится к общему синтаксису и семантике утверждений SAML, а также к протоколу, используемому для запроса и передачи этих утверждений от одного системного объекта к другому. Протокол SAML относится к, что передается, а не к как, (последнее определяется выбором привязки). Таким образом, SAML Core определяет «чистые» утверждения SAML вместе с элементами запроса и ответа SAML.

Привязка SAML определяет, как запросы и ответы SAML отображаются на стандартные протоколы обмена сообщениями или связи. Важной (синхронной) привязкой является привязка SAML SOAP.

Профиль SAML - это конкретное проявление определенного варианта использования с использованием определенной комбинации утверждений, протоколов и привязок.

Утверждения

Утверждение SAML содержит пакет информации о безопасности:

..

Грубо говоря, проверяющая сторона интерпретирует утверждение следующим образом:

Утверждение A было выдано в момент t эмитентом R в отношении субъекта S при условии, что выполняются условия C.

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

операторы аутентификации
утверждения атрибутов
утверждения решения об авторизации

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

Оператор атрибута утверждает, что принципал связан с определенными атрибутами. Атрибут - это просто пара имя – значение. Проверяющие стороны используют атрибуты для принятия решений по управлению доступом.

Заявление о решении об авторизации утверждает, что принципалу разрешено выполнять действие A над ресурсом R при наличии свидетельства E. Выражение утверждений об авторизации в SAML намеренно ограничено. Вместо этого рекомендуется использовать более продвинутые варианты использования XACML.

Протоколы

Ответ протокола SAML

Протокол SAML описывает, как определенные элементы SAML (включая утверждения) упаковываются в элементы запроса и ответа SAML, и дает правила обработки, которым должны следовать объекты SAML при создании или потребляя эти элементы. По большей части протокол SAML - это простой протокол запроса-ответа.

Самый важный тип запроса протокола SAML называется запросом. Поставщик услуг делает запрос напрямую поставщику удостоверений по защищенному обратному каналу. Таким образом, сообщения запроса обычно привязаны к протоколу SOAP.

В соответствии с тремя типами операторов, существует три типа запросов SAML:

запрос аутентификации
запрос атрибута
запрос решения об авторизации

Результат запрос атрибута - это ответ SAML, содержащий утверждение, которое само содержит утверждение атрибута. См. Тему SAML 2.0 для примера запроса / ответа атрибута.

Помимо запросов, SAML 1.1 не определяет никаких других протоколов.

SAML 2.0 значительно расширяет понятие протокола. Следующие протоколы подробно описаны в SAML 2.0 Core:

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

Большинство этих протоколов являются новыми в SAML 2.0.

Привязки

SAML через SOAP через HTTP

Привязка SAML представляет собой отображение сообщения протокола SAML на стандартные форматы обмена сообщениями и / или протоколы связи. Например, привязка SAML SOAP определяет, как сообщение SAML инкапсулируется в конверт SOAP, который сам связан с сообщением HTTP.

SAML 1.1 определяет только одну привязку, SAML SOAP Binding. В дополнение к протоколу SOAP, в SAML 1.1 SSO веб-браузера неявно являются предшественниками привязки HTTP POST, привязки перенаправления HTTP и привязки артефакта HTTP. Однако они не определены явно и используются только в сочетании с системой единого входа веб-браузера SAML 1.1. Понятие привязки не было полностью разработано до SAML 2.0.

SAML 2.0 полностью отделяет концепцию привязки от основного профиля. Фактически, в SAML 2.0 есть фирменная новая спецификация привязки, которая определяет следующие автономные привязки:

Эта реорганизация обеспечивает огромную гибкость: требуется всего лишь В качестве примера единого входа в веб-браузере поставщик услуг может выбрать одну из четырех привязок (HTTP Redirect, HTTP POST и два варианта HTTP Artifact), в то время как поставщик удостоверений имеет три варианта привязки (HTTP POST плюс две формы HTTP Artifact) для всего двенадцать (12) возможных развертываний профиля SSO веб-браузера SAML 2.0.

Профили

Профиль SAML подробно описывает, как утверждения, протоколы и привязки SAML объединяются для поддержки определенного варианта использования. Самый важный профиль SAML - это профиль системы единого входа веб-браузера.

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

Профиль системы единого входа веб-браузера был полностью переработан для SAML 2.0. По сути, SAML 1.1 Browser / Artifact и Browser / POST являются частными случаями SSO веб-браузера SAML 2.0. Последний значительно более гибкий, чем его аналог SAML 1.1, благодаря новому дизайну привязки «plug-and-play» SAML 2.0. В отличие от предыдущих версий, потоки браузера SAML 2.0 начинаются с запроса у поставщика услуг. Это обеспечивает большую гибкость, но потоки, инициированные поставщиком услуг, естественным образом приводят к так называемой проблеме обнаружения поставщика удостоверений, которой сегодня уделяется большое внимание. В дополнение к системе единого входа в веб-браузере, SAML 2.0 представляет множество новых профилей:

Профили единого входа
- Профиль единого входа в веб-браузере
- Профиль расширенного клиента или прокси (ECP)
- Идентификация Профиль обнаружения провайдера
- Профиль единого выхода
- Профиль управления идентификатором имени
Профиль разрешения артефактов
Профиль запроса / запроса утверждения
Профиль сопоставления идентификатора имени
Профили атрибутов SAML

Помимо профиля SSO веб-браузера SAML, некоторые важные сторонние профили SAML включают:

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

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

TLS 1.0+ для безопасности на уровне транспорта
Подпись XML и Шифрование XML для безопасности на уровне сообщений

Требования часто формулируются в терминах (взаимные) аутентификации, целостности и конфиденциальности, оставляя выбор механизма безопасности разработчикам и разработчикам.

Использование

Основной вариант использования SAML называется системой единого входа через веб-браузер (SSO). Пользователь использует пользовательский агент (обычно веб-браузер) для запроса веб-ресурса, защищенного поставщиком услуг SAML. Поставщик услуг, желающий узнать личность запрашивающего пользователя, отправляет запрос аутентификации провайдеру идентификации SAML через пользовательский агент. Результирующий поток протокола изображен на следующей диаграмме.

Единый вход с использованием SAML в веб-браузере

1. Запросить целевой ресурс у SP (только SAML 2.0)

Принципал (через пользовательский агент HTTP) запрашивает целевой ресурс у поставщика услуг:

https://sp.example.com/myresource

Провайдер услуг выполняет проверку безопасности от имени целевого ресурса. Если допустимый контекст безопасности у поставщика услуг уже существует, пропустите шаги 2–7.

2. Перенаправление на службу единого входа в IdP (только SAML 2.0)

Поставщик услуг определяет предпочтительного поставщика удостоверений пользователя (неуказанными способами) и перенаправляет пользовательский агент в службу единого входа в поставщике удостоверений:

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

Значение параметра SAMLRequest(обозначено заполнителем запросвыше) является Base64 кодирование очищенного элемента.

3. Запрос службы SSO у IdP (только SAML 2.0)

Пользовательский агент отправляет запрос GET службе SSO по URL-адресу из шага 2. Служба SSO обрабатывает AuthnRequest(отправлено через параметр запроса URL SAMLRequest) и выполняет проверку безопасности. Если у пользователя нет допустимого контекста безопасности, провайдер идентификации идентифицирует пользователя (подробности опущены).

4. Ответить с помощью формы XHTML

Служба единого входа проверяет запрос и отвечает документом, содержащим форму XHTML:

...

Значение элемента SAMLResponse(обозначено заполнителем ответвыше) является кодировкой base64 элемента .

5. Запросить службу потребителя утверждений в SP

. Пользовательский агент выдает POST-запрос службе потребителя утверждений у поставщика услуг. Значение параметра SAMLResponseберется из формы XHTML на шаге 4.

6. Перенаправление на целевой ресурс

Служба потребителя утверждения обрабатывает ответ, создает контекст безопасности у поставщика службы и перенаправляет пользовательский агент на целевой ресурс.

7. Запросите целевой ресурс у SP еще раз

Пользовательский агент запрашивает целевой ресурс у поставщика услуг (снова):

https://sp.example.com/myresource

8. Ответить запрошенным ресурсом

Поскольку существует контекст безопасности, поставщик услуг возвращает ресурс пользовательскому агенту.

В SAML 1.1 поток начинается с запроса к службе межсайтовой передачи поставщика удостоверений по адресу шаг 3.

В приведенном выше примере потока все изображенные обмены являются обменами по переднему каналу, то есть пользовательский агент HTTP (браузер) связывается с объектом SAML на каждом шаге. В частности, нет обмена по обратным каналам или прямой связи между поставщиком услуг и поставщиком удостоверений. Обмены по переднему каналу приводят к простым потокам протоколов, где все сообщения передаются по значению с использованием простой привязки HTTP (GET или POST). Действительно, процесс, описанный в предыдущем разделе, иногда называют упрощенным профилем единого входа веб-браузера.

В качестве альтернативы, для повышения безопасности или конфиденциальности сообщения могут передаваться по ссылке. Например, провайдер идентификации может предоставить ссылку на утверждение SAML (называемое артефактом) вместо передачи утверждения непосредственно через пользовательский агент. Впоследствии поставщик услуг запрашивает фактическое утверждение через обратный канал. Такой обмен по обратному каналу определяется как обмен сообщениями SOAP (SAML через SOAP через HTTP). Как правило, любой обмен SAML по безопасному обратному каналу осуществляется как обмен сообщениями SOAP.

На обратном канале SAML указывает использование SOAP 1.1. Однако использование SOAP в качестве механизма привязки необязательно. Любое конкретное развертывание SAML будет выбирать любые подходящие привязки.

См. Также

Ссылки

Внешние ссылки