15:44 Язык разметки утверждений безопасности | |
| Язык разметки утверждений безопасности ( SAML , произносится SAM-el ) является открытым стандартом для обмена данными аутентификации и авторизации между сторонами, в частности, между поставщиком удостоверений и поставщиком услуг . SAML - это язык разметки на основе XML для утверждений безопасности (операторов, используемых поставщиками услуг для принятия решений по управлению доступом). SAML также: Набор сообщений протокола на основе XML Набор привязок протокольных сообщений Набор профилей (используя все вышеперечисленное) Самым важным примером использования SAML является единый вход в систему через браузер (SSO). Единый вход в систему относительно легко осуществить в домене безопасности (например, с помощью файлов cookie ), но расширение единого входа через домены безопасности является более сложным и привело к распространению не совместимых с проприетарными технологиями. Профиль единого входа SAML Web Browser был задан и стандартизирован для обеспечения совместимости. (Для сравнения, более свежий протокол OpenID Connect [является альтернативным подходом к SSO веб-браузера.) Спецификация SAML определяет три роли: принципал (обычно пользователь-пользователь), поставщик удостоверений (IdP) и поставщик услуг (SP). В случае первичного использования, адресованного SAML, принципал запрашивает услугу у поставщика услуг. Поставщик услуг запрашивает и получает подтверждение аутентификации от поставщика удостоверений. На основе этого утверждения поставщик услуг может принять решение об управлении доступом , то есть он может решить, выполнять ли услугу для подключенного принципала. В основе утверждения SAML лежит субъект (принципал в контексте определенного домена безопасности), о котором что-то утверждается. Субъект обычно (но не обязательно) человек. Как и в Техническом обзоре SAML V2.0,термины субъект и принципал используются в этом документе взаимозаменяемо. Перед доставкой субъектного подтверждения в SP IdP может запросить некоторую информацию у принципала - такую как имя пользователя и пароль - для аутентификации принципала. SAML определяет Начиная с версии 1.0 SAML подвергся одной незначительной и одной существенной ревизии. SAML 1.0 был принят в качестве стандарта OASIS в ноябре 2002 года SAML 1.1 был ратифицирован как стандарт OASIS в сентябре 2003 года SAML 2.0 стал стандартом OASIS в марте 2005 года Либерти Альянс предоставил свою Систему идентификации личности (ID-FF) для ГКНТ ОАЗИС в сентябре 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 есть некоторые важные различия . В частности, эти две спецификации, несмотря на их общие корни, несовместимы.подтверждения, которое передается из IdP в SP. В SAML один поставщик удостоверений может предоставлять утверждения SAML многим поставщикам услуг. Точно так же один SP может полагаться на утверждения и доверять многим независимым IdP. SAML не указывает метод аутентификации у провайдера идентификации. IdP может использовать имя пользователя и пароль или некоторую другую форму аутентификации, включая многофакторную аутентификацию . Служба каталогов, такая как RADIUS , LDAP или Active Directory, которая позволяет пользователям входить в систему с именем пользователя и паролем, является типичным источником токенов аутентификации у поставщика удостоверений. Популярные интернет-сервисы социальных сетей также предоставляют сервисы идентификации, которые теоретически могут использоваться для поддержки обмена SAML. SAML построен на основе ряда существующих стандартов: Расширяемый язык разметки (XML) Большинство обменов SAML выражены в стандартизированном диалекте XML , который является корнем для имени SAML (язык разметки безопасности). XML-схема (XSD) Утверждения и протоколы SAML указываются (частично) с использованием XML-схемы . Подпись XML Как SAML 1.1, так и SAML 2.0 используют цифровые подписи (на основе стандарта XML Signature ) для аутентификации и целостности сообщений. Шифрование XML Используя шифрование XML , SAML 2.0 предоставляет элементы для зашифрованных идентификаторов имен, зашифрованных атрибутов и зашифрованных утверждений (SAML 1.1 не имеет возможностей шифрования). Сообщается, что шифрование XML имеет серьезные проблемы с безопасностью. Протокол передачи гипертекста (HTTP) SAML в значительной степени опирается на HTTP в качестве протокола связи. МЫЛО SAML определяет использование SOAP , в частности, SOAP 1.1 . SAML определяет основанные на XML утверждения и протоколы, привязки и профили. Термин « ядро SAML» относится к общему синтаксису и семантике утверждений SAML, а также к протоколу, используемому для запроса и передачи этих утверждений от одного системного объекта к другому. Протокол SAML относится к тому, что передается, а не как (последний определяется выбором привязки). Таким образом, SAML Core определяет «пустые» утверждения SAML вместе с элементами запроса и ответа SAML. SAML привязки определяет , как SAML запросы и ответы на карту стандартных сообщений или коммуникационных протоколов. Важной (синхронной) привязкой является привязка SAML SOAP. SAML профиль является конкретным проявлением определенного случая использования , используя определенную комбинацию утверждений, протоколов и привязок. Утверждение SAML содержит пакет информации о безопасности: <собирать: утверждение ...> .. </ Collect: Утверждение> Грубо говоря, полагающаяся сторона интерпретирует утверждение следующим образом: Утверждение 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 в SSO веб-браузера SAML 1.1 неявно присутствуют предшественники привязки HTTP POST, привязки перенаправления HTTP и привязки артефактов HTTP. Однако они не определены явно и используются только в сочетании с SSO SAML 1.1 Web Browser. Понятие привязки не полностью разработано до SAML 2.0. SAML 2.0 полностью отделяет концепцию связывания от базового профиля. Фактически, в SAML 2.0 существует совершенно новая спецификация связывания, которая определяет следующие автономные привязки: SAML SOAP Binding (на основе SOAP 1.1) Обратное связывание SOAP (PAOS) HTTP-перенаправление (GET) Binding HTTP POST Binding Привязка артефактов HTTP Собрать привязку URI Эта реорганизация обеспечивает огромную гибкость: на примере только единого входа в веб-браузер поставщик услуг может выбрать одну из четырех привязок (HTTP Redirect, HTTP POST и два варианта HTTP-артефакта), а у поставщика удостоверений есть три варианта привязки (HTTP POST plus две формы HTTP-артефакта) - всего двенадцать (12) возможных развертываний профиля единого входа веб-браузера SAML 2.0. Профиль SAML подробно описывает, как утверждения, протоколы и привязки SAML объединяются для поддержки определенного варианта использования. Наиболее важным профилем SAML является профиль единого входа в веб-браузере. SAML 1.1 определяет две формы единого входа в веб-браузер: профиль обозревателя / артефакта и профиль обозревателя / POST. Последний передает утверждения по значению, тогда как Браузер / Артефакт передает утверждения по ссылке . Как следствие, Browser / Artifact требует обмена SAML по обратному каналу через SOAP. В SAML 1.1 все потоки начинаются с запроса у провайдера идентификации для простоты. Были предложены собственные расширения базового потока, инициированного IdP (например, Shibboleth ). Профиль единого входа в веб-браузере был полностью переработан для SAML 2.0. Концептуально, SAML 1.1 Browser / Artifact и Browser / POST являются особыми случаями единого входа SAML 2.0 Web Browser. Последний значительно более гибкий, чем его аналог SAML 1.1, благодаря новой технологии привязки «включай и работай» в SAML 2.0. В отличие от предыдущих версий, потоки браузера SAML 2.0 начинаются с запроса у поставщика услуг. Это обеспечивает большую гибкость, но потоки, инициируемые SP, естественно порождают так называемую проблему Identity Provider Discovery , которая является предметом многих исследований сегодня. В дополнение к SSO веб-браузера SAML 2.0 представляет множество новых профилей: Профили SSO Профиль SSO веб-браузера Расширенный профиль клиента или прокси (ECP) Профиль обнаружения провайдера идентификации Профиль единого выхода Профиль управления идентификатором имени Профиль разрешения артефактов Запрос подтверждения / Профиль запроса Профиль отображения идентификатора имени Профили атрибутов SAML Помимо профиля единого входа SAML, некоторые важные сторонние профили SAML включают в себя: Технический комитет OASIS Web Services Security (WSS) Профиль токена SAML OASIS WS-Security Свобода Альянс Структура федерации идентификации личности (ID-FF) Инфраструктура веб-служб Liberty Identity (ID-WSF) Технический комитет OASIS eXtensible Access Control Markup Language (XACML Спецификации SAML рекомендуют, а в некоторых случаях и требуют, различных механизмов безопасности: TLS 1.0+ для безопасности транспортного уровня XML Signature и XML Encryption для обеспечения безопасности на уровне сообщений Требования часто формулируются с точки зрения (взаимной) аутентификации, целостности и конфиденциальности, оставляя выбор механизма безопасности разработчикам и разработчикам. Основной вариант использования SAML называется единой регистрацией в веб-браузере (SSO) . Пользователь использует пользовательский агент (обычно веб-браузер), запрашивает веб-ресурс, защищенный поставщиком услуг 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параметра (обозначено заполнителем requestвыше) - это кодировка Base64 дефлированного <samlp:AuthnRequest> элемента. 3. Запросите службу единого входа в IdP (только SAML 2.0) Пользовательский агент AuthnRequestотправляет запрос GET службе SSO по URL-адресу с шага 2. Служба SSO обрабатывает (отправляется с помощью SAMLRequestпараметра запроса URL) и выполняет проверку безопасности. Если у пользователя нет действительного контекста безопасности, провайдер идентификации идентифицирует пользователя (подробности опущены). 4. Ответить с формой XHTML Служба единого входа проверяет запрос и отвечает документом, содержащим форму XHTML: 5. Запросите подтверждение обслуживания клиентов в SP Пользовательский агент отправляет POST-запрос службе подтверждения клиента у поставщика услуг. Значение SAMLResponseпараметра берется из формы XHTML на шаге 4. 6. Перенаправить на целевой ресурс Служба потребителя утверждений обрабатывает ответ, создает контекст безопасности у поставщика услуг и перенаправляет пользовательский агент на целевой ресурс. 7. Запросите целевой ресурс у SP снова Пользовательский агент запрашивает целевой ресурс у поставщика услуг (снова): https://sp.example.com/myresourceform 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>элемента. 8. Ответить с запрошенным ресурсом Поскольку контекст безопасности существует, поставщик услуг возвращает ресурс агенту пользователя. В SAML 1.1 поток начинается с запроса к службе межсайтовой передачи провайдера идентификации на шаге 3. В приведенном выше примере последовательности все изображенные обмены являются обменами по переднему каналу , то есть пользовательский агент HTTP (браузер) связывается с объектом SAML на каждом этапе. В частности, нет обмена обратным каналом или прямой связи между поставщиком услуг и поставщиком идентификационных данных. Обмен по переднему каналу приводит к простым потокам протоколов, где все сообщения передаются по значению с использованием простой привязки HTTP (GET или POST). Действительно, процесс, описанный в предыдущем разделе, иногда называют облегченным профилем единого входа веб-браузера . Кроме того, для повышения безопасности или конфиденциальности сообщения могут передаваться по ссылке . Например, провайдер идентификации может предоставить ссылку на утверждение SAML (называемое артефактом ) вместо передачи подтверждения непосредственно через пользовательский агент. Впоследствии поставщик услуг запрашивает фактическое подтверждение через обратный канал. Такой обмен по обратному каналу определяется как обмен сообщениями SOAP (SAML через SOAP через HTTP). В общем, любой обмен SAML по безопасному обратному каналу выполняется как обмен сообщениями SOAP. На обратном канале SAML определяет использование SOAP 1.1. Однако использование SOAP в качестве механизма связывания необязательно. Любое данное развертывание SAML будет выбирать любые привязки. | |
|
| |
| Всього коментарів: 0 | |