Security Assertion Markup Language (SAML) — это стандарт XML для обмена данными аутентификации и авторизации между доменами безопасности. SAML — это продукт Технического комитета служб безопасности OASIS (организация) .
SAML 1.1 был ратифицирован в качестве стандарта OASIS в сентябре 2003 года. Критические аспекты SAML 1.1 подробно описаны в официальных документах SAMLCore [1] и SAMLBind. [2] Если вы новичок в SAML, вам, вероятно, следует сначала прочитать вводную тему SAML , а затем документ SAMLOverview [3] от OASIS.
До SAML 1.1, SAML 1.0 был принят в качестве стандарта OASIS в ноябре 2002 года. SAML претерпел одну незначительную (V1.1) и одну значительную ревизию (V2.0) с момента V1.0, которая сама по себе является относительно простым протоколом. Однако SAML 1.0 представляет собой не только исторический интерес, поскольку Федеральная инициатива электронной аутентификации США приняла SAML 1.0 в качестве своей основной технологии.
Версии 1.0 и 1.1 SAML похожи. См. SAMLDiff [4] для конкретных различий между двумя стандартами. Эта статья сосредоточена на SAML 1.1, поскольку это важный стандарт, от которого зависят многие другие стандарты и реализации.
Предупреждение: Разработчики и развёртыватели должны хорошо помнить, что все примеры кода в этой статье не являются нормативными и предназначены только для иллюстрационных целей. Ознакомьтесь со спецификациями OASIS SAML для нормативных требований.
Утверждения SAML содержат утверждения , которые поставщики услуг используют для принятия решений о контроле доступа. Например, утверждения аутентификации заявляют поставщику услуг, что принципал действительно прошел аутентификацию у поставщика удостоверений в определенное время с использованием определенного метода аутентификации. Другая информация о принципале может быть раскрыта в утверждении аутентификации. Например, в приведенном ниже утверждении аутентификации адрес электронной почты принципала утверждается поставщику услуг:
<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> Адрес электронной почты (как в приведенном выше примере) будет достаточным в большом количестве ситуаций. Однако в некоторых случаях требуется дополнительная информация, прежде чем поставщик услуг сможет принять решение о контроле доступа. В качестве примера предположим, что студентам разрешен доступ к данным о стипендиях. Атрибутное утверждение может указывать, имеет ли директор аффилированность «студента», которую поставщик услуг использует для разрешения или запрета доступа (соответственно) к заявке на стипендию:
<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions NotBefore= "..." NotAfter= "..." /> <saml:AuthenticationStatement AuthenticationMethod= "..." AuthenticationInstant= "..." > <saml:Subject> ... </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> ... </saml:Subject> <saml:Attribute AttributeName= "urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace= "urn:mace:shibboleth:1.0:attributeNamespace:uri" > <saml:AttributeValue> участник </saml:AttributeValue> <saml:AttributeValue> студент </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> Атрибуты часто берутся из каталога LDAP , поэтому согласованное представление атрибутов в разных доменах безопасности имеет решающее значение.
В приведенном выше примере, показывающем, как студент может получить доступ к заявке на стипендию, поставщик услуг функционирует как точка реализации политики и точка принятия решения о политике . В некоторых ситуациях может быть предпочтительнее связать точку принятия решения о политике с поставщиком удостоверений. В этом случае поставщик услуг передает URI поставщику удостоверений, который утверждает заявление о решении об авторизации , которое определяет, следует ли разрешить директору доступ к защищенному ресурсу по данному URI.
<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions ... /> <saml:AuthorizationDecisionStatement Decision= "Permit" Resource= "https://sp.example.com/confidential_report.html" > <saml:Subject> ... </saml:Subject> <saml:Action> прочитать </saml:Action> </saml:AuthorizationDecisionStatement> </saml:Assertion> Три типа утверждений не являются взаимоисключающими. Например, как утверждения аутентификации, так и утверждения атрибутов могут быть включены в одно утверждение (как показано выше). Это исключает необходимость совершать последующие круговые обходы между поставщиком услуг и поставщиком удостоверений.
Протокол SAML — это простой протокол запроса-ответа. Запрашивающая сторона SAML отправляет Requestэлемент SAML отвечающей стороне:
<samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:40Z" > <!-- вставьте здесь другие элементы SAML --> </samlp:Request> Аналогично, ответчик SAML возвращает Responseэлемент SAML запрашивающей стороне:
<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:41Z" > <!-- вставьте здесь другие элементы SAML, включая утверждения --> </samlp:Response> Привязки и профили, необходимые для осуществления этого обмена сообщениями, подробно описаны в следующих разделах.
SAML 1.1 формально определяет только одну привязку протокола , привязку SAML SOAP. Совместимая реализация SAML 1.1 должна реализовывать SAML поверх SOAP поверх HTTP (синхронная привязка протокола). Разрешены и другие транспортные механизмы помимо HTTP, при условии соблюдения независимых от протокола аспектов привязки SAML SOAP (см. раздел 3.1.2 SAMLBind [2] ).
Привязка SAML 1.1 SOAP построена поверх версии 1.1 SOAP (нумерация является чисто случайной). Запрашивающая сторона SAML оборачивает Requestэлемент SAML в тело сообщения SOAP. Аналогично, отвечающая сторона SAML возвращает элемент SAML Responseв тело возвращаемого сообщения SOAP. Если возникает ошибка, отвечающая сторона возвращает код ошибки SOAP.
Любая разметка SAML должна быть включена в тело SOAP. SAML 1.1 не определяет никаких заголовков SOAP, специфичных для SAML. Запрашивающая сторона может свободно вставлять любые заголовки SOAP по своему желанию (хотя ни один из них не является обязательным).
Напомним, что в SOAP 1.1 SOAPActionзаголовок HTTP должен быть включен в каждый запрос HTTP (хотя его значение может быть пустым). Запрашивающая сторона SAML может присвоить заголовку следующее значение SOAPAction:
SOAPAction: http://www.oasis-open.org/committees/security
Однако ответчик SAML не должен зависеть от этого значения.
Для запросов и ответов SAML безопасное соединение не требуется, но в тех ситуациях, когда требуется целостность и конфиденциальность сообщений , требуется HTTP через SSL 3.0 или TLS 1.0 с сертификатом на стороне сервера.
SAML-ответчик может вернуть ответ "403 Forbidden", когда он отказывается отвечать запрашивающему SAML. Ответчик должен вернуть ответ "500 Internal Server Error" в случае ошибки SOAP (элемент ошибки SOAP также должен быть включен). В противном случае возвращается ответ "200 OK", даже при наличии ошибки обработки SAML. Такой ответ будет включать элемент SAML Statusв тело SOAP.
В целом профили описывают варианты использования и обмен сообщениями, необходимые для окончательной передачи утверждений от поставщика удостоверений поставщику услуг. SAML 1.1 определяет два профиля единого входа веб-браузера:
Профиль браузера/POST полагается на операцию «push», которая передает утверждение SSO по значению через браузер с помощью HTTP POST. Мы говорим, что поставщик идентификации «push» утверждение поставщику услуг.
Профиль браузера/артефакта использует механизм «pull». Профиль по сути передает утверждение SSO от поставщика удостоверений поставщику услуг по ссылке (через браузер с использованием HTTP Redirect), которая впоследствии разыменовывается через обратный канал обмена (т. е. поставщик услуг «вытягивает» утверждение от поставщика удостоверений с использованием SAML через SOAP через HTTP).
Эти профили поддерживают кросс-доменный единый вход (SSO). Спецификация не определяет никаких дополнительных профилей. В частности, SAML 1.1 не поддерживает профиль для защиты сообщения веб-службы и не поддерживает единый профиль выхода.
Оба профиля SAML 1.1 начинаются в службе передачи между сайтами , которая управляется поставщиком удостоверений. То, как принципал попадает в службу передачи в первую очередь, не диктуется спецификацией. См. разделы 4.1 и 4.2 SAMLOverview [3] для возможных сценариев. На практике клиент, получающий доступ к защищенному ресурсу у поставщика услуг, будет перенаправлен в службу передачи между сайтами у поставщика удостоверений, но точная последовательность шагов, необходимых для этого, не описана в SAML 1.1. (См. раздел 4.3 SAMLOverview [3] для некоторых приблизительных идей по этому поводу.) Этот сценарий подробно рассматривается в SAML 2.0.
После посещения сервиса межсайтовой передачи принципал передается в сервис потребителя утверждений у поставщика услуг. То, как именно принципал передается из сервиса межсайтовой передачи в сервис потребителя утверждений, зависит от используемого профиля. В случае профиля Browser/Artifact используется перенаправление; в случае профиля Browser/POST клиент отправляет запрос POST (с вмешательством пользователя или без него).
Для ускорения обработки службой потребителей утверждений указаны два отдельных URL-адреса:
Эти и другие местоположения конечных точек могут быть записаны в файлах метаданных. То, как именно поставщик удостоверений получает доверенный файл метаданных или иным образом определяет доверенные местоположения конечных точек конкретного поставщика услуг, выходит за рамки SAML 1.1.
Обратите внимание, что поставщик удостоверений SAML 1.1, соответствующий требованиям, должен предоставлять услугу передачи между сайтами. Аналогично поставщик услуг SAML 1.1 должен предоставлять услугу потребителя утверждений.
Профиль SAML 1.1 Browser/POST определяет следующие четыре (4) шага. Терминология, используемая в исходной спецификации, была немного изменена для соответствия спецификации SAML 2.0.
Поток сообщений начинается с запроса, направленного IdP.
Принципал (через HTTP-агента пользователя) запрашивает службу межсайтовой передачи у поставщика удостоверений:
https://idp.example.org/TransferService?TARGET= цель
где targetнаходится желаемый ресурс у поставщика услуг, скажем, https://sp.example.com/home. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS:
GET /TransferService?TARGET=target HTTP / 1.1 Хост : idp.example.orgВ профиле не указано, как URL-адрес службы передачи (с TARGETпараметром) получается пользовательским агентом.
Служба межсайтовой передачи возвращает HTML-документ, содержащий элемент FORM:
HTTP / 1.1 200 OK Тип содержимого : text/html Длина содержимого : nnnn ... < метод формы = "post" действие = "https://sp.example.com/ACS/POST" ... > < тип ввода = "скрытый" имя = "TARGET" значение = "цель" /> < тип ввода = "скрытый" имя = "SAMLResponse" значение = "''ответ''" /> ... < тип ввода = "отправить" значение = "Отправить" /> </ форма > ...где TARGETпараметр был сохранен с шага 1. Значение параметра SAMLResponseпредставляет собой кодировку base64 элемента SAML, Responseнапример:
<samlp:Ответ xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" IssueInstant= "2002-06-19T17:05:37.795Z" > <ds:Подпись xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Подпись> <samlp:Статус> <samlp: Значение кода статуса= "samlp:Успех" /> </samlp:Статус> <saml:Утверждение xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> Ответ SAML должен быть подписан цифровой подписью поставщика удостоверений.
Важно: предполагается, что принципал уже установил контекст безопасности у поставщика удостоверений, в противном случае служба межсайтовой передачи не сможет предоставить заявление об аутентификации в Responseэлементе SAML.
Пользовательский агент запрашивает Assertion Consumer Service у поставщика услуг:
POST /ACS/POST HTTP / 1.1 Хост : sp.example.com Тип содержимого : application/x-www-form-urlencoded Длина содержимого : nnnn TARGET=target&SAMLResponse=responseгде значения параметров TARGETи SAMLResponseберутся из HTML-формы на шаге 2.
Примечание: Для автоматизации отправки формы следующая строка JavaScript может появиться в любом месте страницы:
окно.onload = функция ( ) { документ.формы [ 0 ] .отправить ( ) ; } Конечно, это предполагает, что страница содержит один FORMэлемент ( forms[0]).
Служба потребителей утверждений использует Responseэлемент SAML, создает контекст безопасности у поставщика услуг и перенаправляет агента пользователя на целевой ресурс.
Профиль SAML 1.1 Browser/Artifact определяет следующие шесть (6) шагов. Терминология, используемая в исходной спецификации, была немного изменена для соответствия спецификации SAML 2.0.
Поток сообщений начинается с запроса, направленного IdP.
Принципал (через HTTP-агента пользователя) запрашивает службу межсайтовой передачи у поставщика удостоверений:
https://idp.example.org/TransferService?TARGET= цель
где targetнаходится желаемый ресурс у поставщика услуг, скажем, https://sp.example.com/home. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS:
GET /TransferService?TARGET=target HTTP / 1.1 Хост : idp.example.orgВ профиле не указано, как URL-адрес сервиса передачи (с TARGETпараметром) получается пользовательским агентом.
Принципал перенаправляется в службу Assertion Consumer Service у поставщика услуг, то есть пользовательскому агенту возвращается следующий ответ:
HTTP / 1.1 302 Найдено местоположение : https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifactгде artifact— ссылка на утверждение, которое поставщик удостоверений готов предоставить по запросу.
Важно: предполагается, что принципал уже установил контекст безопасности у поставщика удостоверений, в противном случае служба межсайтовой передачи не сможет предоставить заявление об аутентификации.
Пользовательский агент запрашивает Assertion Consumer Service у поставщика услуг:
https://sp.example.com/ACS/Artifact?TARGET= цель &SAMLart= артефакт
где targetи artifactтакие же, как и раньше. Другими словами, следующий запрос GET выдается пользовательским агентом через SSL/TLS:
GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP / 1.1 Хост : sp.example.comAssertion Consumer Service у поставщика услуг начинает обратный канал обмена с Artifact Resolution Service у поставщика удостоверений. SAML SOAP-сообщение привязано к HTTP POST-запросу:
POST /ArtifactResolutionService HTTP/1.1Хост: idp.example.orgТип содержимого: текст/xmlДлина содержимого: nnnSOAPAction: http://www.oasis-open.org/committees/security <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:03:44.022Z" > <samlp:AssertionArtifact> артефакт </samlp:AssertionArtifact> </samlp:Запрос> </SOAP-ENV:Тело> </SOAP-ENV:Конверт> где artifactранее был отправлен поставщиком удостоверений поставщику услуг на этапах 2 и 3.
Поставщик удостоверений завершает обмен по обратному каналу, отвечая утверждением SAML, привязанным к сообщению SAML SOAP:
HTTP/1.1 200 ОКТип содержимого: текст/xmlДлина содержимого: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" InResponseTo= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:05:37.795Z" > <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope> В этом случае заявление об аутентификации включает в себя NameIdentifierадрес электронной почты принципала.
Служба Assertion Consumer Service анализирует Responseэлемент SAML, создает контекст безопасности у поставщика услуг и перенаправляет агент пользователя на целевой ресурс.