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

Язык разметки утверждений безопасности ( SAML , произносится SAM-el , / ˈ s æ m əl / ) ^[1] — открытый стандарт обмена данными аутентификации и авторизации между сторонами, в частности, между поставщиком удостоверений и поставщиком услуг . SAML — это XML на основе язык разметки для утверждений безопасности (заявления, которые поставщики услуг используют для принятия решений по контролю доступа). SAML также:

Набор сообщений протокола на основе XML.
Набор привязок сообщений протокола
Набор профилей (с использованием всего вышеперечисленного)

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

Обзор

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

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

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

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

История

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

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

Опираясь на этот первоначальный вклад, в ноябре 2002 года OASIS объявил спецификацию языка разметки утверждений безопасности (SAML) 1.0 стандартом OASIS. ^[6]

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

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

Версии

Начиная с версии 1.0, SAML претерпел одну незначительную и одну крупную редакцию.

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 г.

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

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

Дизайн

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

Расширяемый язык разметки (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 имеет серьезные проблемы с безопасностью. ^[10]^[11]
Протокол передачи гипертекста (HTTP): SAML в значительной степени опирается на HTTP в качестве протокола связи.
Простой протокол доступа к объектам (SOAP) : SAML определяет использование SOAP, в частности SOAP 1.1. ^[12]

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

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

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

Утверждения

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

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

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

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

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

Заявления аутентификации
Операторы атрибутов
Заявления о разрешении

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

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

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

Протоколы

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 Привязка — это отображение сообщения протокола SAML на стандартные форматы сообщений и/или протоколы связи. Например, привязка SAML SOAP определяет, как сообщение SAML инкапсулируется в конверт SOAP, который сам привязан к сообщению HTTP.

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

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

Привязка SAML SOAP (на основе SOAP 1.1)
Обратная привязка SOAP (PAOS)
Привязка HTTP-перенаправления (GET)
HTTP-привязка POST
Привязка HTTP-артефакта
Привязка SAML URI

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

Профили

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

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

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

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

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

OASIS по безопасности веб-сервисов (WSS) Технический комитет
Свободный Альянс
Технический комитет OASIS по расширяемому языку разметки контроля доступа (XACML)

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

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

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

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

Использовать

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

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

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

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

https://sp.example.com/myresource

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

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

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

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

Ценность SAMLRequest параметр (обозначается заполнителем request выше) представляет собой Base64 спущенного кодировку <samlp:AuthnRequest> элемент.

3. Запросите услугу единого входа у IdP (только SAML 2.0).

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

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

Служба единого входа проверяет запрос и отвечает документом, содержащим форму 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 элемент (обозначается заполнителем response выше) — это кодировка base64 <samlp:Response> элемент.

5. Запросите службу обработки утверждений у поставщика услуг.

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

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

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

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

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

https://sp.example.com/myresource

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

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

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

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

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

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

См. также

Ссылки

^ «Что такое SAML? — Определение слова из компьютерного словаря Webopedia» . Вебопедия.com. 25 июня 2002 года . Проверено 21 сентября 2013 г.
^ Дж. Хьюз и др. Профили для языка разметки утверждений безопасности OASIS (SAML) 2.0. Стандарт OASIS, март 2005 г. Идентификатор документа: saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (для последних рабочих проект этой спецификации с исправлениями см.: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf )
^ Н. Рагузис и др. Технический обзор языка разметки утверждений безопасности (SAML) 2.0. Проект комитета OASIS 02, март 2008 г. Идентификатор документа: sstc-saml-tech-overview-2.0-cd-02 https://wiki.oasis-open.org/security/Saml2TechOverview
^ «SAML: секрет централизованного управления идентификацией» . InformationWeek.com. 23 ноября 2004 г. Проверено 23 мая 2014 г.
^ Малер, Ева (9 января 2001 г.). «Протокол от 9 января 2001 года Службы безопасности ТК телекон» . услуги безопасности в oasis-open (список рассылки) . Проверено 7 апреля 2011 г.
^ «История САМЛ» . SAMLXML.org. 05.12.2007 . Проверено 22 мая 2014 г.
^ Конор П. Кэхилл. «Обзор технологии Liberty» (PDF) . Свободный Альянс . Проверено 25 августа 2017 г.
^ Jump up to: ^а ^б ^с «Google, NTT и GSA США развертывают SAML 2.0 для управления цифровой идентификацией» . Журнал Oracle. 29 января 2008 г. Проверено 22 мая 2014 г.
^ П. Мишра; и др. (Май 2003 г.), Различия между языком разметки утверждений безопасности OASIS (SAML) V1.1 и V1.0 (PDF) , OASIS, sstc-saml-diff-1.1-draft-01 , получено 7 апреля 2011 г.
^ «Как взломать шифрование XML» (PDF) . Ассоциация вычислительной техники . 19 октября 2011 года . Проверено 31 октября 2014 г.
^ «Исследователи Рубля нарушают стандарт W3C» . Рурский университет в Бохуме . 19 октября 2011 г. Архивировано из оригинала 24 ноября 2011 г. Проверено 29 июня 2012 г.
^ МЫЛО 1.1

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

[ISnTY-1] «Что такое SAML? — Определение слова из компьютерного словаря Webopedia» . Вебопедия.com. 25 июня 2002 года . Проверено 21 сентября 2013 г.

[SAMLProf20-2] Дж. Хьюз и др. Профили для языка разметки утверждений безопасности OASIS (SAML) 2.0. Стандарт OASIS, март 2005 г. Идентификатор документа: saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf (для последних рабочих проект этой спецификации с исправлениями см.: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf )

[SAMLTechOverview20-3] Н. Рагузис и др. Технический обзор языка разметки утверждений безопасности (SAML) 2.0. Проект комитета OASIS 02, март 2008 г. Идентификатор документа: sstc-saml-tech-overview-2.0-cd-02 https://wiki.oasis-open.org/security/Saml2TechOverview

[92xv0-4] «SAML: секрет централизованного управления идентификацией» . InformationWeek.com. 23 ноября 2004 г. Проверено 23 мая 2014 г.

[QmSYw-5] Малер, Ева (9 января 2001 г.). «Протокол от 9 января 2001 года Службы безопасности ТК телекон» . услуги безопасности в oasis-open (список рассылки) . Проверено 7 апреля 2011 г.

[hVZwx-6] «История САМЛ» . SAMLXML.org. 05.12.2007 . Проверено 22 мая 2014 г.

[D9bCd-7] Конор П. Кэхилл. «Обзор технологии Liberty» (PDF) . Свободный Альянс . Проверено 25 августа 2017 г.

[OiGthD-8] Jump up to: ^а ^б ^с «Google, NTT и GSA США развертывают SAML 2.0 для управления цифровой идентификацией» . Журнал Oracle. 29 января 2008 г. Проверено 22 мая 2014 г.

[Pu5b0-9] П. Мишра; и др. (Май 2003 г.), Различия между языком разметки утверждений безопасности OASIS (SAML) V1.1 и V1.0 (PDF) , OASIS, sstc-saml-diff-1.1-draft-01 , получено 7 апреля 2011 г.

[J2KVQ-10] «Как взломать шифрование XML» (PDF) . Ассоциация вычислительной техники . 19 октября 2011 года . Проверено 31 октября 2014 г.

[0wAHF-11] «Исследователи Рубля нарушают стандарт W3C» . Рурский университет в Бохуме . 19 октября 2011 г. Архивировано из оригинала 24 ноября 2011 г. Проверено 29 июня 2012 г.

[K6G4v-12] МЫЛО 1.1

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]