САМЛ 2.0

Security Assertion Markup Language 2.0 ( SAML 2.0 ) — это версия стандарта SAML для обмена идентификаторами аутентификации и авторизации между доменами безопасности . SAML 2.0 — это основанный на XML протокол , который использует токены безопасности , содержащие утверждения, для передачи информации о принципале (обычно конечном пользователе) между органом SAML, называемым поставщиком удостоверений , и потребителем SAML, называемым поставщиком услуг . SAML 2.0 обеспечивает веб-ориентированный, междоменный единый вход (SSO), что помогает сократить административные издержки на распространение нескольких токенов аутентификации для пользователя. SAML 2.0 был ратифицирован как стандарт OASIS в марте 2005 года, заменив SAML 1.1 . Критические аспекты SAML 2.0 подробно описаны в официальных документах SAMLCore, ^[1] SAMLBind, ^[2] SAMLProf, ^[3] и SAMLMeta. ^[4]

В создании SAML 2.0 приняли участие около 30 человек из более чем 24 компаний и организаций. В частности, и это следует особо отметить, Liberty Alliance передал OASIS свою спецификацию Identity Federation Framework (ID-FF), которая стала основой спецификации SAML 2.0. Таким образом, SAML 2.0 представляет собой конвергенцию SAML 1.1 , Liberty ID-FF 1.2 и Shibboleth 1.3.

Утверждения SAML 2.0

Утверждение — это пакет информации, который предоставляет ноль или более утверждений, сделанных органом SAML. Утверждения SAML обычно делаются о субъекте, представленном элементом <Subject>. Спецификация SAML 2.0 определяет три различных вида утверждений, которые могут быть созданы органом SAML. Все утверждения, определенные SAML, связаны с субъектом. Определены три вида утверждений:

Заявление об аутентификации: Субъект утверждения был аутентифицирован определенным способом в определенное время.
Утверждение атрибута: субъект утверждения связан с предоставленными атрибутами.
Заявление о решении об авторизации: запрос на разрешение субъекту утверждения получить доступ к указанному ресурсу был удовлетворен или отклонен. ^{[ необходима цитата ]}

Важным типом утверждения SAML является так называемое утверждение "bearer", используемое для упрощения единого входа в веб-браузер. Вот пример кратковременного утверждения bearer, выданного поставщиком удостоверений (https://idp.example.org/SAML2) поставщику услуг (https://sp.example.com/SAML2). Утверждение включает как утверждение аутентификации, так <saml:AuthnStatement>и утверждение атрибута <saml:AttributeStatement>, которые, предположительно, поставщик услуг использует для принятия решения о контроле доступа. Префикс saml:представляет пространство имен утверждений SAML V2.0.

Пример SAML

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs= "http://www.w3.org/2001/XMLSchema" ID= "_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> < /saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue xsi:type= "xs:string" > член </saml:AttributeValue> <saml:AttributeValue xsi:type= "xs:string" > staff </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Обратите внимание, что в приведенном выше примере <saml:Assertion>элемент содержит следующие дочерние элементы:

элемент <saml:Issuer>, содержащий уникальный идентификатор поставщика удостоверений
элемент <ds:Signature>, содержащий сохраняющую целостность цифровую подпись (не показана) над <saml:Assertion>элементом
элемент <saml:Subject>, который идентифицирует аутентифицированного принципала (но в этом случае личность принципала скрыта за непрозрачным временным идентификатором из соображений конфиденциальности)
элемент <saml:Conditions>, который задает условия, при которых утверждение следует считать действительным
элемент <saml:AuthnStatement>, описывающий процесс аутентификации у поставщика удостоверений
элемент <saml:AttributeStatement>, который утверждает многозначный атрибут, связанный с аутентифицированным принципалом

На словах утверждение кодирует следующую информацию:

Утверждение («b07b804c-7c29-ea16-7300-4f3d6f7928ac») было выдано в момент времени «2004-12-05T09:22:05Z» поставщиком удостоверений (https://idp.example.org/SAML2) относительно субъекта (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) исключительно для поставщика услуг (https://sp.example.com/SAML2).

В заявлении об аутентификации, в частности, утверждается следующее:

Принципал, указанный в <saml:Subject>элементе, был аутентифицирован в момент времени «2004-12-05T09:22:00Z» с помощью пароля, отправленного по защищенному каналу.

Аналогично утверждение атрибута утверждает, что:

Директор, указанный в <saml:Subject>элементе, имеет атрибуты «сотрудник» и «участник» в этом учреждении.

Протоколы SAML 2.0

В SAMLCore указаны следующие протоколы: ^[1]

Запрос утверждения и протокол запроса
Протокол запроса аутентификации
Протокол разрешения артефактов
Протокол управления идентификатором имени
Протокол единого выхода
Протокол сопоставления идентификаторов имен

Наиболее важный из этих протоколов — протокол запроса аутентификации — подробно обсуждается ниже.

Протокол запроса аутентификации

В SAML 1.1 профили единого входа веб-браузера инициируются поставщиком удостоверений (IDP) , то есть незапрошенный <samlp:Response>элемент передается от поставщика удостоверений поставщику услуг (через браузер). (Префикс samlp:обозначает пространство имен протокола SAML.)

Однако в SAML 2.0 поток начинается с поставщика услуг, который выдает явный запрос аутентификации поставщику удостоверений. Результирующий протокол запроса аутентификации является важной новой функцией SAML 2.0.

Когда принципал (или субъект, действующий от имени принципала) желает получить утверждение, содержащее заявление об аутентификации, <samlp:AuthnRequest>поставщику удостоверений передается элемент:

 <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "aaf23196-1773-2113-474a-fe114412ab72" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" AttributeConsumingServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

Вышеуказанный <samlp:AuthnRequest>элемент, который неявно запрашивает утверждение, содержащее заявление об аутентификации, был, очевидно, выпущен поставщиком услуг (https://sp.example.com/SAML2) и впоследствии представлен поставщику идентификации (через браузер). Поставщик идентификации аутентифицирует принципала (при необходимости) и выдает ответ аутентификации, который передается обратно поставщику услуг (снова через браузер).

Протокол разрешения артефактов

Сообщение SAML передается от одного субъекта к другому либо по значению , либо по ссылке . Ссылка на сообщение SAML называется артефактом . Получатель артефакта разрешает ссылку, отправляя <samlp:ArtifactResolve>запрос непосредственно издателю артефакта, который затем отвечает фактическим сообщением, на которое ссылается артефакт.

Предположим, например, что поставщик удостоверений отправляет следующий <samlp:ArtifactResolve>запрос напрямую поставщику услуг (через обратный канал):

 <samlp:ArtifactResolve xmlns:samlp= "urn:oasis :names:tc:SAML:2.0 :protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- сообщение ArtifactResolve ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Подпись> <samlp:Артефакт> AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8= </samlp:Артефакт> </samlp:АртефактРешение>

В ответ поставщик услуг возвращает элемент SAML, на который ссылается вложенный артефакт. Этот протокол формирует основу HTTP Artifact Binding.

Привязки SAML 2.0

Привязки , поддерживаемые SAML 2.0, описаны в спецификации привязок (SAMLBind ^[2] ):

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

Для Web Browser SSO обычно используются HTTP Redirect Binding и HTTP POST Binding. Например, поставщик услуг может использовать HTTP Redirect для отправки запроса, в то время как поставщик удостоверений использует HTTP POST для передачи ответа. Этот пример иллюстрирует, что выбор привязки субъектом не зависит от выбора привязки его партнером.

Привязка перенаправления HTTP

Сообщения протокола SAML могут передаваться непосредственно в строке запроса URL запроса HTTP GET. Поскольку длина URL на практике ограничена, привязка HTTP Redirect подходит для коротких сообщений, таких как message <samlp:AuthnRequest>. Более длинные сообщения (например, содержащие подписанные или зашифрованные утверждения SAML, такие как SAML Responses) обычно передаются через другие привязки, такие как HTTP POST Binding.

Запросы или ответы SAML, передаваемые через HTTP Redirect, имеют параметр строки запроса SAMLRequestили SAMLResponseсоответственно. Перед отправкой сообщение дефлатируется ( без заголовка и контрольной суммы), кодируется base64 и URL-кодируется в указанном порядке. После получения процесс выполняется в обратном порядке для восстановления исходного сообщения.

Например, кодирование <samlp:AuthnRequest>сообщения выше дает:

https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2 Mabbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr%2FRbRp63K3pL5rPhYOpkVdY ib%2FCon%2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8s BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2FBK5MNo1F dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0%2Bin8xutxYOvZL18NK UqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P%2FAXv4C

Вышеприведенное сообщение (отформатированное для удобства чтения) может быть подписано для дополнительной безопасности. На практике все данные, содержащиеся в <samlp:AuthnRequest>, например, Issuerкоторые содержат идентификатор SP и NameIDPolicy, были заранее согласованы между IdP и SP (путем ручного обмена информацией или через метаданные SAML). В этом случае подписание запроса не является ограничением безопасности. Когда <samlp:AuthnRequest>содержит информацию, заранее не известную IdP, например, URL-адрес службы потребителя утверждений, подпись запроса рекомендуется в целях безопасности.

HTTP-привязка POST

В следующем примере и поставщик услуг, и поставщик удостоверений используют HTTP POST-связь. Первоначально поставщик услуг отвечает на запрос от пользовательского агента документом, содержащим форму XHTML:

 < метод формы  = "post" действие = "https://idp.example.org/SAML2/SSO/POST" ... > < тип ввода = "hidden" имя = "SAMLRequest" значение = "''request''" />        ... другой входной параметр.... </ форма >

Значение параметра SAMLRequest— это base64-кодировка элемента <samlp:AuthnRequest>, которая передается поставщику идентификации через браузер. Служба SSO у поставщика идентификации проверяет запрос и отвечает документом, содержащим другую форму XHTML:

 < метод формы  = "post" действие = "https://sp.example.com/SAML2/SSO/POST" ... > < тип ввода = "hidden" имя = "SAMLResponse" значение = "''response''" />        ... </ форма >

Значением параметра SAMLResponseявляется кодировка элемента base64 <samlp:Response>, которая также передается поставщику услуг через браузер.

Для автоматизации отправки формы в любом месте XHTML-страницы может появиться следующая строка JavaScript:

 окно.onload = функция ( ) { документ.формы [ 0 ] .отправить ( ) ; }

Конечно, это предполагает, что первый элемент формы на странице содержит указанный выше formэлемент, содержащий SAMLResponse ( forms[0]).

Привязка артефакта HTTP

HTTP Artifact Binding использует Artifact Resolution Protocol и SAML SOAP Binding (по HTTP) для разрешения сообщения SAML по ссылке. Рассмотрим следующий конкретный пример. Предположим, что поставщик услуг хочет отправить сообщение <samlp:AuthnRequest>поставщику удостоверений. Первоначально поставщик услуг передает артефакт поставщику удостоверений через HTTP-перенаправление:

https://idp.example.org/SAML2/SSO/Artifact?SAMLart= артефакт

Затем поставщик идентификации отправляет <samlp:ArtifactResolve>запрос (такой как ArtifactResolveRequest, показанный ранее) непосредственно поставщику услуг через обратный канал. Наконец, поставщик услуг возвращает <samlp:ArtifactResponse>элемент, содержащий указанное <samlp:AuthnRequest>сообщение:

 <samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "_d84a49e5958803dedcff4c984c2b0d95" InResponseTo= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- сообщение ArtifactResponse ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "_306f8ec5b618f361c70b6ffb1480eade" Версия= "2.0" IssueInstant= "2004-12-05T09:21:59Z" Назначение= "https://idp.example.org/SAML2/SSO/Artifact" ProtocolBinding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Исполнитель> https://sp.example.com/SAML2 </saml:Исполнитель> <samlp:NameIDPolicy AllowCreate= "false" Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

Конечно, поток может пойти и в другом направлении, то есть поставщик удостоверений может выдать артефакт, и на самом деле это более распространено. См., например, пример профиля "двойного артефакта" далее в этой теме.

Формат артефакта

В общем случае артефакт SAML 2.0 определяется следующим образом (SAMLBind ^[2] ):

SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact) ТипКод := Байт1Байт2 EndpointIndex := Байт1Байт2

Таким образом, артефакт SAML 2.0 состоит из трех компонентов: двухбайтового TypeCode, двухбайтового EndpointIndexи произвольной последовательности байтов, называемой RemainingArtifact. Эти три фрагмента информации объединяются и кодируются в base64 для получения полного артефакта.

Уникально TypeCodeидентифицирует формат артефакта. SAML 2.0 предопределяет только один такой артефакт типа 0x0004. Это EndpointIndexссылка на конкретную конечную точку разрешения артефакта, управляемую издателем артефакта (который может быть либо IdP, либо SP, как упоминалось ранее). RemainingArtifact, который определяется определением типа, является «мясом» артефакта.

Формат артефакта типа 0x0004 далее определяется следующим образом:

ТипКод := 0x0004 ОставшийсяАртефакт := SourceId MessageHandle SourceId := 20-байтовая_последовательность MessageHandle := 20-байтовая_последовательность

Таким образом, артефакт типа 0x0004 имеет размер 44 байта (незакодирован). Это SourceIdпроизвольная последовательность байтов, хотя на практике это SourceIdхэш SHA-1 entityID эмитента. Это MessageHandleслучайная последовательность байтов, которая ссылается на сообщение SAML, которое эмитент артефакта готов выдавать по требованию.

Например, рассмотрим этот артефакт типа 0x0004 в шестнадцатеричной кодировке:

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

Если присмотреться, можно увидеть TypeCode(0x0004) и EndpointIndex(0x0000) в начале артефакта. Следующие 20 байт — это хэш SHA-1 entityID эмитента (https://idp.example.org/SAML2), за которым следуют 20 случайных байтов. Кодировка base64 этих 44 байтов — это то, что вы видите в примере ArtifactResolveRequest выше.

Профили SAML 2.0

В SAML 2.0, как и в SAML 1.1, основным вариантом использования по-прежнему является единый вход в веб-браузер, но область применения SAML 2.0 шире, чем в предыдущих версиях SAML, как следует из следующего исчерпывающего списка профилей:

Профили единого входа
- Профиль единого входа в веб-браузер
- Расширенный профиль клиента или прокси (ECP)
- Профиль обнаружения поставщика удостоверений
- Профиль единого выхода
- Профиль управления идентификатором имени
Профиль разрешения артефактов
Профиль запроса/утверждения
Профиль сопоставления идентификатора имени
Профили атрибутов SAML
- Базовый профиль атрибутов
- Профиль атрибутов X.500/LDAP
- Профиль атрибута UUID
- Профиль атрибутов DCE PAC
- Профиль атрибутов XACML

Хотя количество поддерживаемых профилей довольно велико, спецификация профилей (SAMLProf ^[3] ) упрощена, поскольку аспекты привязки каждого профиля были вынесены в отдельную спецификацию привязок (SAMLBind ^[2] ).

Профиль единого входа в веб-браузер

SAML 2.0 определяет профиль единого входа веб-браузера, включающий поставщика удостоверений (IdP), поставщика услуг (SP) и принципала, владеющего агентом пользователя HTTP. У поставщика услуг есть четыре привязки, из которых можно выбирать, в то время как у поставщика удостоверений — три, что приводит к двенадцати возможным сценариям развертывания. Ниже мы описываем три из этих сценариев развертывания.

Запрос перенаправления SP; ответ POST IdP

Это один из наиболее распространенных сценариев. Поставщик услуг отправляет запрос SAML в службу SSO IdP с помощью привязки HTTP-Redirect. Поставщик удостоверений возвращает ответ SAML в службу SP Assertion Consumer Service с помощью привязки HTTP-POST.

SAML 2.0 Web Browser SSO (привязка перенаправления SP/ответ IdP POST)

Поток сообщений начинается с запроса защищенного ресурса у поставщика услуг.

1. Запросить целевой ресурс у SP

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

https://sp.example.com/myresource

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

Поставщик услуг может использовать любой механизм для обнаружения поставщика удостоверений, который будет использоваться, например, спросить пользователя, использовать предварительно настроенный IdP и т. д.

2. Перенаправление в службу единого входа IdP

Поставщик услуг генерирует соответствующий SAMLRequest (и RelayState, если таковой имеется), затем перенаправляет браузер в службу единого входа IdP, используя стандартное перенаправление HTTP 302 .

Расположение перенаправления 302 : https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

Токен RelayState— это непрозрачная ссылка на информацию о состоянии, поддерживаемую поставщиком услуг. Значение параметра SAMLRequest— это дефляционное, закодированное в base64 и URL-кодированное значение элемента <samlp:AuthnRequest>:

 <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

SAMLRequest может быть подписан с использованием ключа подписи SP. Однако обычно это не является необходимым.

3. Запросите услугу SSO у IdP

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

GET  /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token  HTTP / 1.1 Хост :  idp.example.org

где значения параметров SAMLRequestи RelayStateсовпадают с указанными в перенаправлении. Служба SSO на провайдере идентификации обрабатывает <samlp:AuthnRequest>элемент (путем URL-декодирования, base64-декодирования и расширения запроса в указанном порядке) и выполняет проверку безопасности. Если у пользователя нет допустимого контекста безопасности, провайдер идентификации идентифицирует пользователя любым механизмом (подробности опущены).

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

Служба SSO проверяет запрос и отвечает документом, содержащим форму XHTML:

 < метод формы  = "post" действие = "https://sp.example.com/SAML2/SSO/POST" ... > < тип ввода = "скрытый" имя = "SAMLResponse" значение = "ответ" /> < тип ввода = "скрытый" имя = "RelayState" значение = "токен" /> ... < тип ввода = "отправить" значение = "Отправить" /> </ форма >

Значение параметра RelayStateсохранено с шага 3. Значение параметра SAMLResponseпредставляет собой кодировку base64 следующего <samlp:Response>элемента:

 <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ОТПРАВЛЕННОЕ УТВЕРЖДЕНИЕ ДОЛЖНО БЫТЬ ПОДПИСАНО --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" > NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. Запросите услугу Assertion Consumer Service в SP

Пользовательский агент отправляет запрос POST в Assertion Consumer Service у поставщика услуг:

POST  /SAML2/SSO/POST  HTTP / 1.1 Хост :  sp.example.com Тип содержимого :  application/x-www-form-urlencoded Длина содержимого :  nnn SAMLResponse = ответ & RelayState = токен

где значения параметров SAMLResponseи RelayStateберутся из формы XHTML на шаге 4.

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

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

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

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

https://sp.example.com/myresource

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

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

Запрос SP POST; Ответ IdP POST

Это относительно простое развертывание профиля единого входа веб-браузера SAML 2.0 (SAMLProf ^[3] ), в котором и поставщик услуг (SP), и поставщик удостоверений (IdP) используют привязку HTTP POST.

Единый вход через веб-браузер SAML 2.0 (POST)

Поток сообщений начинается с запроса защищенного ресурса у SP.

1. Запросить целевой ресурс у SP

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

https://sp.example.com/myresource

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

Поставщик услуг отвечает документом, содержащим форму XHTML:

 < метод формы  = "post" действие = "https://idp.example.org/SAML2/SSO/POST" ... > < тип ввода = "скрытый" имя = "SAMLRequest" значение = "запрос" /> < тип ввода = "скрытый" имя = "RelayState" значение = "токен" /> ... < тип ввода = "отправить" значение = "Отправить" /> </ форма >

Токен RelayState— это непрозрачная ссылка на информацию о состоянии, поддерживаемую поставщиком услуг. Значение параметра SAMLRequest— это кодировка base64 следующего <samlp:AuthnRequest>элемента:

 <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

Перед <samlp:AuthnRequest>вставкой элемента в форму XHTML он сначала кодируется в формате base64.

3. Запросите услугу SSO у IdP

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

POST  /SAML2/SSO/POST  HTTP / 1.1 Хост :  idp.example.org Тип содержимого :  application/x-www-form-urlencoded Длина содержимого :  nnnSAMLRequest = запрос & RelayState = токен

где значения параметров SAMLRequestи RelayStateберутся из формы XHTML на шаге 2. Служба SSO обрабатывает <samlp:AuthnRequest>элемент (путем URL-декодирования, base64-декодирования и расширения запроса в указанном порядке) и выполняет проверку безопасности. Если у пользователя нет допустимого контекста безопасности, поставщик идентификации идентифицирует пользователя (подробности опущены).

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

Служба SSO проверяет запрос и отвечает документом, содержащим форму XHTML:

 < метод формы  = "post" действие = "https://sp.example.com/SAML2/SSO/POST" ... > < тип ввода = "скрытый" имя = "SAMLResponse" значение = "ответ" /> < тип ввода = "скрытый" имя = "RelayState" значение = "токен" /> ... < тип ввода = "отправить" значение = "Отправить" /> </ форма >

 <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/POST" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- ОТПРАВЛЕННОЕ УТВЕРЖДЕНИЕ ДОЛЖНО БЫТЬ ПОДПИСАНО --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" > NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response>

5. Запросите услугу Assertion Consumer Service в SP

Пользовательский агент отправляет запрос POST в службу потребителя утверждений у поставщика услуг:

POST  /SAML2/SSO/POST  HTTP / 1.1 Хост :  sp.example.com Тип содержимого :  application/x-www-form-urlencoded Длина содержимого :  nnn SAMLResponse = ответ & RelayState = токен

где значения параметров SAMLResponseи RelayStateберутся из формы XHTML на шаге 4.

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

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

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

https://sp.example.com/myresource

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

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

Артефакт перенаправления SP; Артефакт перенаправления IdP

Это сложное развертывание SAML 2.0 Web Browser SSO Profile (SAMLProf ^[3] ), где как поставщик услуг (SP), так и поставщик удостоверений (IdP) используют привязку HTTP Artifact. Оба артефакта доставляются в соответствующие конечные точки через HTTP GET.

SAML 2.0 Веб-браузер SSO (Артефакт)

Поток сообщений начинается с запроса защищенного ресурса у SP:

1. Запросить целевой ресурс у SP

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

https://sp.example.com/myresource

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

2. Перенаправление на службу единого входа (SSO) на IdP

Поставщик услуг перенаправляет агента пользователя на службу единого входа (SSO) у поставщика удостоверений. Параметр RelayStateи SAMLartпараметр добавляются к URL перенаправления.

3. Запросите услугу SSO у IdP

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

https://idp.example.org/SAML2/SSO/Artifact?SAMLart= артефакт_1 &RelayState= токен

где token— непрозрачная ссылка на информацию о состоянии, хранящуюся у поставщика услуг, а artifact_1— артефакт SAML, оба выдаются на шаге 2.

4. Запросите услугу разрешения артефактов у SP

Служба SSO разыменовывает артефакт, отправляя <samlp:ArtifactResolve>элемент, привязанный к сообщению SAML SOAP, в службу разрешения артефактов у поставщика услуг:

 <samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" Destination= "https://sp.example.com/SAML2/ArtifactResolution" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- сообщение ArtifactResolve ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_1'' </samlp:Artifact> </samlp:ArtifactResolve>

где значение элемента <samlp:Artifact>— артефакт SAML, переданный на шаге 3.

5. Ответьте с помощью SAML AuthnRequest

Служба разрешения артефактов у поставщика услуг возвращает <samlp:ArtifactResponse>элемент (содержащий <samlp:AuthnRequest>элемент), привязанный к сообщению SAML SOAP, в службу SSO у поставщика удостоверений:

 <samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_2" InResponseTo= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- сообщение ArtifactResponse ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Версия= "2.0" IssueInstant= "2004-12-05T09:21:59Z" Назначение= "https://idp.example.org/SAML2/SSO/Artifact" ProtocolBinding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" AssertionConsumerServiceURL= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Исполнитель> https://sp.example.com/SAML2 </saml:Исполнитель> <samlp:ИмяIDПолитика AllowCreate= "false" Формат = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

Служба SSO обрабатывает <samlp:AuthnRequest>элемент и выполняет проверку безопасности. Если у пользователя нет допустимого контекста безопасности, поставщик идентификации идентифицирует пользователя (подробности опущены).

6. Перенаправление в Assertion Consumer Service

Служба SSO у поставщика удостоверений перенаправляет агента пользователя в службу потребителя утверждений у поставщика услуг. Предыдущий RelayStateпараметр и новый SAMLartпараметр добавляются к URL перенаправления.

7. Запросите услугу Assertion Consumer Service в SP

Пользовательский агент запрашивает услугу потребителя утверждений у поставщика услуг:

https://sp.example.com/SAML2/SSO/Artifact?SAMLart= артефакт_2 &RelayState= токен

где token— значение токена из шага 3, а artifact_2— артефакт SAML, выпущенный на шаге 6.

8. Запросите услугу разрешения артефактов в IdP

Служба потребителя утверждений разыменовывает артефакт, отправляя <samlp:ArtifactResolve>элемент, привязанный к сообщению SAML SOAP, в службу разрешения артефактов у поставщика удостоверений:

 <samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:04Z" Destination= "https://idp.example.org/SAML2/ArtifactResolution" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <!-- сообщение ArtifactResolve ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_2'' </samlp:Artifact> </samlp:ArtifactResolve>

где значение элемента <samlp:Artifact>— артефакт SAML, переданный на шаге 7.

9. Ответьте утверждением SAML

Служба разрешения артефактов у поставщика удостоверений возвращает <samlp:ArtifactResponse>элемент (содержащий <samlp:Response>элемент), привязанный к сообщению SAML SOAP, службе потребителя утверждений у поставщика услуг:

 <samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "identifier_5" InResponseTo= "identifier_4" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <!-- сообщение ArtifactResponse ДОЛЖНО быть подписано --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_6" InResponseTo= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_7" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- элемент Subject обязателен --> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > [email protected] </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_3" Recipient= "https://sp.example.com/SAML2/SSO/Artifact" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Тема> <saml:Условия NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:Ограничение аудитории> <saml:Аудитория> https://sp.example.com/SAML2 </saml:Аудитория>                                                     </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_7" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> < /saml:AuthnContext > </saml:AuthnStatement> </saml:Assertion> </samlp:Response> </samlp:ArtifactResponse>

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

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

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

https://sp.example.com/myresource

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

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

Профиль обнаружения поставщика удостоверений

Профиль обнаружения поставщика удостоверений SAML 2.0 вводит следующие концепции:

Общий домен
Файл cookie общего домена
Служба записи файлов cookie общего домена
Служба чтения файлов cookie общего домена

В качестве гипотетического примера общего домена предположим, что Example UK (example.co.uk) и Example Deutschland (example.de) принадлежат виртуальной организации Example Global Alliance (example.com). В этом примере домен example.com является общим доменом. И Example UK, и Example Deutschland присутствуют в этом домене (uk.example.com и de.example.com, соответственно).

Файл cookie Common Domain — это защищенный файл cookie браузера, ограниченный общим доменом. Для каждого пользователя браузера этот файл cookie хранит список истории недавно посещенных IdP. Имя и значение файла cookie указаны в профиле обнаружения IdP (SAMLProf ^[3] ).

После успешного акта аутентификации IdP запрашивает Common Domain Cookie Writing Service . Эта служба добавляет уникальный идентификатор IdP к общему доменному cookie. SP, когда он получает неаутентифицированный запрос на защищенный ресурс, запрашивает Common Domain Cookie Reading Service , чтобы обнаружить последний использованный IdP пользователя браузера.

Профиль запроса/утверждения

Профиль запроса/утверждения — это общий профиль, который охватывает многочисленные типы так называемых запросов, использующих следующие элементы SAML 2.0:

элемент <samlp:AssertionIDRequest>, который используется для запроса утверждения с учетом его уникального идентификатора ( ID)
элемент <samlp:SubjectQuery>, который является абстрактной точкой расширения, позволяющей определять новые запросы SAML на основе субъектов
элемент <samlp:AuthnQuery>, который используется для запроса существующих утверждений аутентификации относительно данного субъекта от Центра аутентификации
элемент <samlp:AttributeQuery>, который используется для запроса атрибутов по заданному предмету из Центра атрибутов
элемент <samlp:AuthzDecisionQuery>, который используется для запроса решения об авторизации от доверенной третьей стороны

Привязка SAML SOAP часто используется совместно с запросами.

Запрос атрибута SAML

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

 <samlp:AttributeQuery xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "aaf23196-1773-2113-474a-fe114412ab72" Версия= "2.0" IssueInstant= "2006-07-17T20:31:40Z" > <saml: Формат эмитента= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509Имя_темы" > [email protected],OU=Пользователь,O=NCSA-TEST,C=US </saml:Издатель> <saml:Тема> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > [email protected],OU=User,O=NCSA-TEST,C=US </saml:NameID> </saml:Subject> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Имя= "urn:oid:2.5.4.42" FriendlyName= "givenName" > </saml:Attribute> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Имя= " "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > </saml:Attribute> </samlp:AttributeQuery>

Обратите внимание, что в данном случае это Issuer. SubjectИногда это называется атрибутом self-query . Поставщик удостоверений может вернуть следующее утверждение, обернутое в <samlp:Response>элемент (не показано):

 <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns: xs= "http://www.w3.org/2001/XMLSchema" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" ID= "_33776a319493ad607b7ab3e689482e45" Версия= "2.0" IssueInstant= "2006-07-17T20:31:41Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature> ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > [email protected],OU=User,O=NCSA-TEST,C=US </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" > <saml:SubjectConfirmationData> <ds:KeyInfo> <ds:X509Data> <!-- сертификат X.509 принципала --> <ds:X509Certificate> MIICiDCCAXACCQDE+9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp+tsaJINM0VaBaZ3t+tSXknelYife nCc2O3yaX76aq53QMXy+5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC g2bHOg8uSh+Fbv3lHih4lBJ5MCS2buJfsR7dlr/xsadU2RcCAwEAATANBgkqhkiG 9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7+I1j0LO24UlKvbLzd2OPvcFTCv6fVHx Ejk0QxaZXJhreZ6+rIdiMXrEzlRdJEsNMxtDW8++sVp6avoB5EX1y3ez+CEAIL4g cjvKZUR4dMryWshWIBHKFFul+r7urUgvWI12KbMeE9KP+kiiiiTskLcKgFzngw1J selmHhTcTCrcDocn5yO2+d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp E9iVI0wdPE038uQIJJTXlhsMMLvUGVh/c0ReJBn92Vj4dI/yy6PtY/8ncYLYNkjg oVN0J/ymOktn9lTlFyTiuY4OuJsZRO1+zWLy9g== </ ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </saml:SubjectConfirmationData> </saml:SubjectConfirmation> </saml:Subject> <!-- время жизни утверждения ограничено сертификатом X.509 принципала --> <saml:Conditions NotBefore= "2006-07-17T20:31:41Z" NotOnOrAfter= "2006-07-18T20:21:41Z" > </saml:Условия> <saml:AuthnStatement AuthnInstant= "2006-07-17T20:31:41Z" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient                                                    </saml:AuthnContextClassRef> </saml:AuthnContext> </ saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > <saml:AttributeValue xsi:type= "xs:string" > Том </saml:AttributeValue> </saml:Attribute> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.1466.115.121.1.26" FriendlyName= "mail" > <saml:AttributeValue xsi:type= "xs:string" > [email protected] </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

В отличие от BearerAssertion, показанного ранее, это утверждение имеет более длительный срок службы, соответствующий сроку службы сертификата X.509, который принципал использовал для аутентификации у поставщика удостоверений. Более того, поскольку утверждение подписано, пользователь может передать это утверждение проверяющей стороне, и пока пользователь может доказать владение соответствующим закрытым ключом (отсюда и название «держатель ключа»), проверяющая сторона может быть уверена, что утверждение является подлинным.

Метаданные SAML 2.0

Буквально, метаданные — это то, что заставляет SAML работать (или работать хорошо). Некоторые важные применения метаданных включают:

Поставщик услуг готовится передать <samlp:AuthnRequest>элемент поставщику удостоверений через браузер. Как поставщик услуг узнает, что поставщик удостоверений является подлинным, а не каким-то злым поставщиком удостоверений, пытающимся выудить пароль пользователя? Поставщик услуг сверяется со своим списком доверенных поставщиков удостоверений в метаданных, прежде чем выдать запрос на аутентификацию.
В предыдущем сценарии, как поставщик услуг узнает, куда отправить пользователя с запросом аутентификации? Поставщик услуг ищет заранее согласованное местоположение конечной точки доверенного поставщика удостоверений в метаданных .
Поставщик удостоверений получает <samlp:AuthnRequest>элемент от поставщика услуг через браузер. Как поставщик удостоверений узнает, что поставщик услуг является подлинным, а не каким-то злым поставщиком услуг, пытающимся собрать персональную идентификационную информацию о пользователе? Поставщик удостоверений сверяется со своим списком доверенных поставщиков услуг в метаданных, прежде чем выдать ответ аутентификации.
В предыдущем сценарии, как поставщик идентификации шифрует утверждение SAML, чтобы доверенный поставщик услуг (и только доверенный поставщик услуг) мог расшифровать утверждение. Поставщик идентификации использует сертификат шифрования поставщика услуг в метаданных для шифрования утверждения.
Продолжая предыдущий сценарий, как поставщик удостоверений узнает, куда отправить пользователя с ответом аутентификации? Поставщик удостоверений ищет заранее согласованное местоположение конечной точки доверенного поставщика услуг в метаданных .
Как поставщик услуг узнает, что ответ аутентификации пришел от доверенного поставщика удостоверений? Поставщик услуг проверяет подпись на утверждении, используя открытый ключ поставщика удостоверений из метаданных .
Как поставщик услуг узнает, где разрешить артефакт, полученный от доверенного поставщика удостоверений? Поставщик услуг ищет заранее согласованное местоположение конечной точки службы разрешения артефактов поставщика удостоверений из метаданных .

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

Метаданные поставщика удостоверений

Поставщик удостоверений публикует данные о себе в <md:EntityDescriptor>элементе:

 <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- вставьте элемент ds:Signature (пропущен) --> <!-- вставьте элемент md:IDPSSODescriptor (ниже) --> <md:Organization> <md:OrganizationName xml:lang= "en" > Некая некоммерческая организация Нью - Йорка </md:OrganizationName> <md:OrganizationDisplayName xml:lang = "en" > Некая некоммерческая организация </md:OrganizationDisplayName> <md :OrganizationURL xml:lang= "en" > https://www.example.org/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Техническая поддержка SAML </md:SurName> <md:EmailAddress> mailto:[email protected] </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

Обратите внимание на следующие сведения об этом дескрипторе сущности:

Атрибут entityID— это уникальный идентификатор сущности.
Атрибут validUntilуказывает дату истечения срока действия метаданных.
Элемент <ds:Signature>(который был опущен для простоты) содержит цифровую подпись, которая гарантирует подлинность и целостность метаданных.
Организация, указанная в <md:Organization>элементе, «отвечает за сущность», описанную дескриптором сущности (раздел 2.3.2 SAMLMeta ^[4] ).
Контактная информация в <md:ContactPerson>элементе определяет технический контакт, ответственный за сущность. Возможны несколько контактов и типов контактов. См. раздел 2.3.2.2 SAMLMeta. ^[4]

По определению поставщик удостоверений управляет службой единого входа (SSO), которая поддерживает профиль единого входа SAML Web Browser, указанный в SAMLProf. ^[3] См., например, поставщика удостоверений, описанного в <md:IDPSSODescriptor>элементе, показанном в следующем разделе.

Метаданные службы SSO

Служба SSO у поставщика удостоверений описана в <md:IDPSSODescriptor>элементе:

 <md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://idp.example.org/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:SingleSignOnService Привязка= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Местоположение= "https://idp.example.org/SAML2/SSO/Redirect" /> <md:SingleSignOnService Привязка= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Местоположение= "https://idp.example.org/SAML2/SSO/POST" /> <md:SingleSignOnService Привязка= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Местоположение= "https://idp.example.org/SAML2/Artifact" /> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > <saml:AttributeValue> участник </saml:AttributeValue> <saml:AttributeValue> студент </saml:AttributeValue> <saml:AttributeValue > преподаватель </saml:AttributeValue> <saml:AttributeValue> сотрудник </saml:AttributeValue> <saml:AttributeValue> персонал </saml:AttributeValue> </saml:Атрибут> </md:IDPSSODescriptor>

Предыдущий элемент метаданных описывает службу SSO у поставщика удостоверений. Обратите внимание на следующие детали этого элемента:

Программное обеспечение поставщика удостоверений настроено с помощью закрытого ключа подписи SAML и/или закрытого ключа обратного канала TLS. Соответствующий открытый ключ включен в <md:KeyDescriptor use="signing">элемент метаданных IdP. Материал ключа был исключен из дескриптора ключа для краткости.
Атрибут Bindingэлемента указывает, что для разрешения артефактов следует использовать <md:ArtifactResolutionService>привязку SAML SOAP (SAMLBind ^{[2] ).}
Атрибут Locationэлемента <md:ArtifactResolutionService>используется на шаге 8 профиля «двойного артефакта».
Значение атрибута indexэлемента <md:ArtifactResolutionService>используется при EndpointIndexпостроении артефакта SAML типа 0x0004.
Элементы <md:NameIDFormat>указывают, какие форматы идентификаторов имен SAML (SAMLCore ^[1] ) поддерживает служба единого входа.
Атрибутами Bindingэлементов <md:SingleSignOnService>являются стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind ^[2] ).
Атрибут Locationэлемента <md:SingleSignOnService>, поддерживающего привязку HTTP POST, используется на шаге 2 профиля «double POST».
Атрибут Locationэлемента <md:SingleSignOnService>, поддерживающего привязку HTTP-артефакта, используется на шаге 2 профиля «двойной артефакт».
Элемент <saml:Attribute>описывает атрибут, который поставщик удостоверений готов утверждать (в соответствии с политикой). <saml:AttributeValue>Элементы перечисляют возможные значения, которые может принимать атрибут.

Как отмечалось в начале этого раздела, значения атрибутов Locationиспользуются поставщиком услуг для маршрутизации сообщений SAML, что сводит к минимуму возможность организации атаки типа «человек посередине» недобросовестным поставщиком удостоверений .

Метаданные поставщика услуг

Как и поставщик удостоверений, поставщик услуг публикует данные о себе в <md:EntityDescriptor>элементе:

 <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- вставьте элемент ds:Signature (пропущен) --> <!-- вставьте элемент md:SPSSODescriptor (см. ниже) --> <md:Organization> <md:OrganizationName xml:lang = "en" > Некоторые коммерческие поставщики из Калифорнии </md:OrganizationName> <md: OrganizationDisplayName xml:lang = "en" > Некоторые коммерческие поставщики </md:OrganizationDisplayName> <md: OrganizationURL xml:lang= "en" > https://www.example.com/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Техническая поддержка SAML </md:SurName> <md:EmailAddress> mailto:[email protected] </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

Обратите внимание на следующие сведения об этом дескрипторе сущности:

Атрибут entityID— это уникальный идентификатор сущности.
Атрибут validUntilуказывает дату истечения срока действия метаданных.
Элемент <ds:Signature>(который был опущен для простоты) содержит цифровую подпись, которая гарантирует подлинность и целостность метаданных.
Организация, указанная в <md:Organization>элементе, «отвечает за сущность», описанную дескриптором сущности (раздел 2.3.2 SAMLMeta ^[4] ).
Контактная информация в <md:ContactPerson>элементе определяет технический контакт, ответственный за сущность. Возможны несколько контактов и типов контактов. См. раздел 2.3.2.2 SAMLMeta. ^[4]

По определению поставщик услуг управляет службой потребителя утверждений, которая поддерживает профиль единого входа SAML Web Browser, указанный в SAMLProf. ^[3] См., например, поставщика услуг, описанного в <md:SPSSODescriptor>элементе, показанном в следующем разделе.

Метаданные службы утверждения потребителя

Утверждение потребительской услуги содержится в <md:SPSSODescriptor>элементе:

 <md:SPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use= "encryption" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://sp.example.com/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://sp.example.com/SAML2/SSO/POST" /> <md:AssertionConsumerService index= "1" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://sp.example.com/SAML2/Artifact" /> <md:AttributeConsumingService isDefault= "true" index= "1" > <md: ServiceName xml:lang= "en" > Портал поставщика услуг </md:ServiceName> <md:RequestedAttribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName= "eduPersonAffiliation" > </md:RequestedAttribute> </md:AttributeConsumingService> </md:SPSSODescriptor>

Обратите внимание на следующие сведения об <md:SPSSODescriptor>элементе метаданных:

Программное обеспечение поставщика услуг настроено с помощью закрытого ключа подписи SAML и/или закрытого ключа обратного канала TLS. Соответствующий открытый ключ включен в <md:KeyDescriptor use="signing">элемент метаданных SP. Материал ключа был исключен из дескриптора ключа для краткости.
Аналогично программное обеспечение поставщика услуг настроено с закрытым ключом дешифрования SAML. Открытый ключ шифрования SAML включен в <md:KeyDescriptor use="encryption">элемент метаданных SP. Материал ключа был исключен из дескриптора ключа для краткости.
Атрибут indexэлемента <md:AssertionConsumerService>используется как значение атрибута AssertionConsumerServiceIndexв <samlp:AuthnRequest>элементе.
Атрибутами Bindingэлементов <md:AssertionConsumerService>являются стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind ^[2] ).
Атрибут Locationэлемента <md:AssertionConsumerService>, поддерживающего привязку HTTP POST ( index="0"), используется на шаге 4 профиля «double POST».
Атрибут Locationэлемента <md:AssertionConsumerService>, поддерживающего привязку HTTP-артефакта ( index="1"), используется на шаге 6 профиля «двойной артефакт».
Этот <md:AttributeConsumingService>элемент используется поставщиком удостоверений для формирования <saml:AttributeStatement>элемента, который отправляется поставщику услуг совместно с единым входом веб-браузера.
Атрибут indexэлемента <md:AttributeConsumingService>используется в качестве значения атрибута AttributeConsumingServiceIndexв <samlp:AuthnRequest>элементе.

Как отмечалось в начале этого раздела, значения атрибутов Locationиспользуются поставщиком удостоверений для маршрутизации сообщений SAML, что сводит к минимуму возможность организации атаки типа «человек посередине» недобросовестным поставщиком услуг .

Агрегаты метаданных

В предыдущих примерах каждый <md:EntityDescriptor>элемент показан как имеющий цифровую подпись. Однако на практике несколько <md:EntityDescriptor>элементов группируются вместе под <md:EntitiesDescriptor>элементом с единой цифровой подписью по всему агрегату:

 <md:EntitiesDescriptor validUntil= "2013-03-22T23:00:00Z" xmlns:md= "urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- вставьте элемент ds:Signature (пропущен) --> <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" > ... </md:EntityDescriptor> <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" > ... </md:EntityDescriptor> </md:EntitiesDescriptor>

Обратите внимание на следующие сведения об указанном выше <md:EntitiesDescriptor>элементе:

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

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

Смотрите также

Ссылки

Основные ссылки:

^ abc S. Cantor и др. Утверждения и протоколы для языка разметки утверждений безопасности OASIS (SAML) V2.0 – Errata Composite. Рабочий черновик 07, 8 сентября 2015 г. Идентификатор документа sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf
^ abcdefg S. Cantor и др. Привязки для OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Рабочий черновик 06, 8 сентября 2015 г. Идентификатор документа sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf
^ abcdefg Дж. Хьюз и др. Профили для OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Рабочий черновик 07, 8 сентября 2015 г. Идентификатор документа sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf
^ abcde S. Cantor и др. Метаданные для OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Рабочий черновик 05, 8 сентября 2015 г. Идентификатор документа sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata-2.0-wd-05.pdf

Вторичные ссылки:

P. Mishra et al. Требования соответствия для OASIS Security Assertion Markup Language (SAML) V2.0 – Errata Composite. Рабочий проект 04, 1 декабря 2009 г. Идентификатор документа sstc-saml-conformance-errata-2.0-wd-04 https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata-2.0-wd-04-diff.pdf

Н. Рагузис и др., Технический обзор языка разметки утверждений безопасности (SAML) V2.0. Проект комитета OASIS, март 2008 г. Идентификатор документа sstc-saml-tech-overview-2.0-cd-02 http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

P. Madsen et al., SAML V2.0 Executive Overview. Проект комитета OASIS, апрель 2005 г. Идентификатор документа sstc-saml-tech-overview-2.0-cd-01-2col http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf

J. Kemp et al. Контекст аутентификации для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-authn-context-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

Ф. Хирш и др. Вопросы безопасности и конфиденциальности для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-sec-consider-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

J. Hodges и др. Глоссарий для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-glossary-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf

Устаревшие ссылки:

P. Mishra et al. Требования соответствия для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-conformance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf

S. Cantor и др. Утверждения и протоколы для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

S. Cantor и др. Привязки для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

S. Cantor и др. Профили для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

S. Cantor и др. Метаданные для языка разметки утверждений безопасности OASIS (SAML) V2.0. Стандарт OASIS, март 2005 г. Идентификатор документа saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf