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

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Язык разметки утверждения безопасности»  -  новости  · газеты  · книги  · научный сотрудник  · JSTOR ( март 2014 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

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

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

Обзор [ править ]

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

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

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

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

История [ править ]

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

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

Основываясь на этих первоначальных вкладах, в ноябре 2002 года OASIS объявил о спецификации Security Assertion Markup Language (SAML) V1.0 в качестве стандарта OASIS. ^[6]

Между тем Liberty Alliance , большой консорциум компаний, некоммерческих и государственных организаций, предложил расширение стандарта SAML под названием Liberty Identity Federation Framework (ID-FF). ^[7] Как и его предшественник 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 стало обычным явлением в правительстве, высших учебных заведениях и коммерческих предприятиях по всему миру. ^[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 г.

Версии 1.0 и 1.1 SAML похожи, хотя существуют небольшие различия. ^[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 есть некоторые важные различия . В частности, две спецификации, несмотря на их общие корни, несовместимы.

Дизайн [ править ]

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: Утверждение ...> .. </ saml: Утверждение>

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

Утверждение был выдан в момент времени т эмитентом R относительно предмета S если условия С справедливы.

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

1. Заявления об аутентификации
2. Заявления атрибутов
3. Заявления об авторизации

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

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

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

Протоколы [ править ]

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

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

В соответствии с тремя типами операторов есть три типа запросов SAML:

1. Запрос аутентификации
2. Запрос атрибута
3. Запрос на решение об авторизации

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

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

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

Эта реорганизация обеспечивает огромную гибкость: взяв в качестве примера только систему единого входа в веб-браузере, поставщик услуг может выбрать одну из четырех привязок (HTTP Redirect, HTTP POST и два варианта HTTP Artifact), в то время как поставщик удостоверений имеет три варианта привязки (HTTP POST плюс две формы HTTP-артефакта), всего двенадцать (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

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

• Технический комитет по безопасности веб-сервисов OASIS (WSS)
  • Профиль токена SAML OASIS WS-Security
• Liberty Alliance
  • Фреймворк Liberty Identity Federation Framework (ID-FF)
  • Платформа веб-служб Liberty Identity (ID-WSF)
• OASIS eXtensible Access Control Markup Language (XACML) Технический комитет
  • SAML 2.0 Профиль XACML v2.0

Безопасность [ править ]

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

• TLS  1.0+ для безопасности транспортного уровня
• XML Signature и XML Encryption для обеспечения безопасности на уровне сообщений

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

Используйте [ редактировать ]

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

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

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

https://sp.example.com/myresource

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 выберет подходящие привязки.

См. Также [ править ]

• Метаданные SAML
• Продукты и услуги на основе SAML
• Управление идентификацией
• Системы управления идентификацией
• Федеративная идентичность
• Информационная карта
• WS-Федерация
• OAuth
• OpenID Connect

Ссылки [ править ]

Внешние ссылки [ править ]

• Технический комитет служб безопасности OASIS
• Титульные страницы: язык разметки утверждений безопасности (SAML)
• Обучающее видео: десять вещей, которые нужно знать о SAML
• Как изучать и изучать SAML
• Демистификация SAML
• Первый общедоступный поставщик удостоверений SAML 2.0
• Даниэль Блюм (2003). Federated ID набирает обороты . IDG Network World Inc. стр. 42.
• SAML 101
• Как реализовать корпоративное управление пользователями с поддержкой SAML для Java Single Sign-On