Язык разметки утверждений безопасности ( SAML , произносится как СЭМ-ЭЛ , / ˈsæməl / ) [ 1] — открытый стандарт для обмена данными аутентификации и авторизации между сторонами, в частности, между поставщиком удостоверений и поставщиком услуг . SAML — это основанный на XML язык разметки для утверждений безопасности (заявлений, которые поставщики услуг используют для принятия решений по контролю доступа). SAML также:
Важным вариантом использования, к которому обращается SAML, является единый вход в веб-браузер (SSO). Единый вход относительно легко реализовать в домене безопасности (например, с помощью файлов cookie ), но расширение SSO на домены безопасности сложнее и привело к распространению несовместимых фирменных технологий. Профиль 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] С этой целью в течение первых двух месяцев того года в SSTC была передана следующая интеллектуальная собственность:
Основываясь на этих первоначальных вкладах, в ноябре 2002 года OASIS объявил спецификацию Security Assertion Markup Language (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 внесла ID-FF 1.2 в OASIS, тем самым посеяв семена для следующей основной версии SAML. В марте 2005 года SAML 2.0 был объявлен стандартом OASIS. SAML 2.0 представляет собой конвергенцию Liberty ID-FF и фирменных расширений, предоставленных проектом Shibboleth , а также ранних версий самого SAML. Большинство реализаций SAML поддерживают v2.0, в то время как многие все еще поддерживают v1.1 для обратной совместимости. К январю 2008 года развертывания SAML 2.0 стали обычным явлением в правительственных, высших учебных заведениях и коммерческих предприятиях по всему миру. [8]
Начиная с версии 1.0, SAML претерпел одну незначительную и одну существенную ревизию.
В сентябре 2003 года Альянс Свободы представил свою структуру Федерации идентичности (ID-FF) в OASIS SSTC:
Версии 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 есть некоторые важные различия. В частности, эти две спецификации, несмотря на их общие корни, несовместимы. [8]
SAML построен на ряде существующих стандартов:
SAML определяет утверждения и протоколы, привязки и профили на основе XML. Термин SAML Core относится к общему синтаксису и семантике утверждений SAML, а также к протоколу, используемому для запроса и передачи этих утверждений от одного системного объекта к другому. Протокол SAML относится к тому, что передается, а не как (последнее определяется выбором привязки). Таким образом, SAML Core определяет «голые» утверждения SAML вместе с элементами запроса и ответа SAML.
Привязка SAML определяет, как запросы и ответы SAML отображаются на стандартные протоколы обмена сообщениями или связи. Важной (синхронной) привязкой является привязка SAML SOAP.
Профиль SAML — это конкретное проявление определенного варианта использования с использованием определенной комбинации утверждений, протоколов и привязок.
Утверждение SAML содержит пакет информации о безопасности:
<saml:Утверждение ...> .. </saml:Утверждение>
Грубо говоря, полагающаяся сторона интерпретирует утверждение следующим образом:
Утверждение 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 Binding. Помимо SOAP, в SAML 1.1 Web Browser SSO неявно присутствуют предшественники HTTP POST Binding, HTTP Redirect Binding и HTTP Artifact Binding. Однако они не определены явно и используются только в сочетании с SAML 1.1 Web Browser SSO. Понятие привязки не было полностью разработано до SAML 2.0.
SAML 2.0 полностью отделяет концепцию привязки от базового профиля. Фактически, в SAML 2.0 есть совершенно новая спецификация привязки , которая определяет следующие автономные привязки:
Такая реорганизация обеспечивает колоссальную гибкость: если взять в качестве примера только единый вход веб-браузера, поставщик услуг может выбрать одну из четырех привязок (HTTP Redirect, HTTP POST и две разновидности HTTP Artifact), тогда как поставщик удостоверений имеет три варианта привязки (HTTP POST плюс две формы HTTP Artifact), что в общей сложности дает двенадцать возможных вариантов развертывания профиля единого входа веб-браузера 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 являются особыми случаями единого входа веб-браузера SAML 2.0. Последний значительно более гибок, чем его аналог SAML 1.1, благодаря новому дизайну привязки "plug-and-play" SAML 2.0. В отличие от предыдущих версий, потоки браузера SAML 2.0 начинаются с запроса у поставщика услуг. Это обеспечивает большую гибкость, но потоки, инициированные поставщиком услуг, естественным образом приводят к так называемой проблеме обнаружения поставщика удостоверений , которая сегодня является предметом многих исследований. Помимо единого входа веб-браузера, SAML 2.0 вводит множество новых профилей:
Помимо профиля единого входа веб-браузера SAML, некоторые важные сторонние профили SAML включают в себя:
Спецификации SAML рекомендуют, а в некоторых случаях и предписывают, различные механизмы безопасности:
Требования часто формулируются в терминах (взаимной) аутентификации, целостности и конфиденциальности, оставляя выбор механизма безопасности разработчикам и разработчикам.
Основной вариант использования SAML называется Web Browser Single Sign-On (SSO) . Пользователь использует пользовательский агент (обычно веб-браузер) для запроса веб-ресурса, защищенного поставщиком услуг SAML . Поставщик услуг, желающий узнать личность запрашивающего пользователя, отправляет запрос на аутентификацию поставщику удостоверений SAML через пользовательский агент. Результирующий поток протокола изображен на следующей диаграмме.
https://sp.example.com/myresourceПоставщик услуг выполняет проверку безопасности от имени целевого ресурса. Если допустимый контекст безопасности у поставщика услуг уже существует, пропустите шаги 2–7.
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=requestЗначение параметра
SAMLRequest(обозначенное заполнителем requestвыше) представляет собой кодировку Base64 сжатого <samlp:AuthnRequest> элемента.AuthnRequest(отправлено через SAMLRequestпараметр запроса URL) и выполняет проверку безопасности. Если у пользователя нет допустимого контекста безопасности, поставщик идентификации идентифицирует пользователя (подробности опущены). < метод формы = "post" действие = "https://sp.example.com/SAML2/SSO/POST" ... > < тип ввода = "скрытый" имя = "SAMLResponse" значение = "ответ" /> ... < тип ввода = "отправить" значение = "Отправить" /> </ форма > SAMLResponse(обозначенное заполнителем responseвыше) представляет собой кодировку элемента base64 <samlp:Response>.SAMLResponseберется из формы XHTML на шаге 4.https://sp.example.com/myresource
В SAML 1.1 поток начинается с запроса к службе межсайтовой передачи поставщика удостоверений на шаге 3.
В примере потока выше все изображенные обмены являются обменами по фронтальному каналу , то есть HTTP-агент пользователя (браузер) взаимодействует с сущностью SAML на каждом шаге. В частности, нет никаких обменов по обратному каналу или прямых коммуникаций между поставщиком услуг и поставщиком удостоверений. Обмены по фронтальному каналу приводят к простым потокам протоколов, где все сообщения передаются по значению с использованием простой привязки HTTP (GET или POST). Действительно, поток, описанный в предыдущем разделе, иногда называют профилем SSO облегченного веб-браузера .
В качестве альтернативы, для повышения безопасности или конфиденциальности, сообщения могут передаваться по ссылке . Например, поставщик удостоверений может предоставить ссылку на утверждение SAML (называемое артефактом ) вместо передачи утверждения напрямую через пользовательский агент. Впоследствии поставщик услуг запрашивает фактическое утверждение через обратный канал. Такой обмен по обратному каналу определяется как обмен сообщениями SOAP (SAML через SOAP через HTTP). В общем случае любой обмен SAML по защищенному обратному каналу осуществляется как обмен сообщениями SOAP.
На обратном канале SAML указывает использование SOAP 1.1. Однако использование SOAP в качестве механизма привязки является необязательным. Любое конкретное развертывание SAML выберет любые подходящие привязки.