SAML 2.0 - SAML 2.0

Язык разметки утверждения безопасности
Положение делОпубликовано
Год началсяНоябрь 2003 г.
Последняя версияV2.0
Март 2005 г.
Предварительная версияV2.0 с исправлениями
Май 2019
ОрганизацияОАЗИС
КомитетТехнический комитет OASIS Security Services (SAML)
СокращениеSAML
Интернет сайтOASIS SAML Вики

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

SAML 2.0 был ратифицирован как ОАЗИС Стандарт в марте 2005 г., заменив SAML 1.1. Критические аспекты SAML 2.0 подробно описаны в официальных документах SAMLCore,[1] SAMLBind,[2] САМЛПроф,[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, Свобода ID-FF 1.2, и Shibboleth 1.3.

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

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

  • Утверждение аутентификации: Субъект утверждения был аутентифицирован определенными средствами в определенное время.
  • Утверждение атрибута: субъект утверждения связан с предоставленными атрибутами.
  • Утверждение решения об авторизации: запрос на разрешение субъекту утверждения доступа к указанному ресурсу был предоставлен или отклонен.

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

Пример SAML

   xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"   xmlns: xs ="http://www.w3.org/2001/XMLSchema"   ID ="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75"   Версия ="2.0"   IssueInstant ="2004-12-05T09: 22: 05Z">   <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>        xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>   <saml:Subject>            Формат ="urn: oasis: names: tc: SAML: 2.0: nameid-format: transient">       3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID>            Метод ="урна: оазис: имена: tc: SAML: 2.0: cm: bearer">                InResponseTo ="aaf23196-1773-2113-474a-fe114412ab72"         Получатель ="https://sp.example.com/SAML2/SSO/POST"         NotOnOrAfter ="2004-12-05T09: 27: 05Z"/>     </saml:SubjectConfirmation>   </saml:Subject>        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>        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>            xmlns: x500 ="урна: оазис: имена: tc: SAML: 2.0: профили: атрибут: X500"       x500: Кодировка ="LDAP"       NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"       Имя ="urn: oid: 1.3.6.1.4.1.5923.1.1.1.1"       FriendlyName ="eduPersonAffiliation">                xsi: type ="xs: строка">член</saml:AttributeValue>                xsi: type ="xs: строка">сотрудники</saml:AttributeValue>     </saml:Attribute>   </saml:AttributeStatement> </saml:Assertion>

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

  • а <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> element является сотрудником этого учреждения.

Протоколы SAML 2.0

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

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

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

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="aaf23196-1773-2113-474a-fe114412ab72"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 59Z"    AssertionConsumerServiceIndex ="0"    AttributeConsumingServiceIndex ="0">    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>          AllowCreate ="истинный"      Формат ="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> запрос напрямую поставщику услуг (через обратный канал):

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="_cce4ee769ed970b501d680f697989d14"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 58Z">    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>    <!-- an ArtifactResolve message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Artifact>AAQAAMh48 / 1oXIM + sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8 =</samlp:Artifact>  </samlp:ArtifactResolve>

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

Привязки SAML 2.0

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

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

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

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

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

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

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

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

Привязка HTTP POST

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

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

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

  <форма метод="почтовый" действие="https://sp.example.com/SAML2/SSO/POST" ...>    <Вход тип="скрытый" имя="SAMLResponse" ценить="''отклик''" />    ...  </форма>

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

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

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

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

Связывание артефактов HTTP

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

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

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

      xmlns: samlp ="urn: oasis: names: tc: SAML: 2.0: протокол"    ID ="_d84a49e5958803dedcff4c984c2b0d95"    InResponseTo ="_cce4ee769ed970b501d680f697989d14"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 59Z">    <!-- an ArtifactResponse message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Status>              Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>    </samlp:Status>          xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"      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:Issuer>https://sp.example.com/SAML2</saml:Issuer>              AllowCreate ="ложный"        Формат ="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) TypeCode: = Byte1Byte2 EndpointIndex: = Byte1Byte2

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

В ТипКод однозначно определяет формат артефакта. SAML 2.0 предопределяет только один такой артефакт типа 0x0004. В EndpointIndex - это ссылка на конкретную конечную точку разрешения артефактов, управляемую издателем артефактов (который может быть IdP или SP, как упоминалось ранее). В ОстающийсяАртефакт, который определяется определением типа, является «мясом» артефакта.

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

 TypeCode: = 0x0004 RemainingArtifact: = SourceId MessageHandle SourceId: = 20-byte_sequence MessageHandle: = 20-byte_sequence

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

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

 00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

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

Профили SAML 2.0

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

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

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

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

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

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

SAML 2.0 Web Browser SSO (SP Redirect Bind / IdP POST Response)

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

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

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

 https://sp.example.com/myresource

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

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

2. Перенаправление на службу SSO IdP

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 59Z"    AssertionConsumerServiceIndex ="0">    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>          AllowCreate ="истинный"      Формат ="urn: oasis: names: tc: SAML: 2.0: nameid-format: transient"/>  </samlp:AuthnRequest>

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

3. Запросите услугу единого входа в IdP.

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

ПОЛУЧАТЬ / SAML2 / SSO / Redirect? SAMLRequest = запрос & RelayState = токен HTTP/1.1Хозяин: idp.example.org

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

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

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_2"    InResponseTo ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 22: 05Z"    Пункт назначения ="https://sp.example.com/SAML2/SSO/POST">    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>    <samlp:Status>              Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>    </samlp:Status>          xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"      ID ="идентификатор_3"      Версия ="2.0"      IssueInstant ="2004-12-05T09: 22: 05Z">      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>      <!-- a POSTed assertion MUST be signed -->              xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>      <saml:Subject>                  Формат ="urn: oasis: names: tc: SAML: 2.0: nameid-format: transient">          3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID>                  Метод ="урна: оазис: имена: tc: SAML: 2.0: cm: bearer">                      InResponseTo ="идентификатор_1"            Получатель ="https://sp.example.com/SAML2/SSO/POST"            NotOnOrAfter ="2004-12-05T09: 27: 05Z"/>        </saml:SubjectConfirmation>      </saml:Subject>              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>              AuthnInstant ="2004-12-05T09: 22: 00Z"        SessionIndex ="идентификатор_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. Запросить службу поддержки утверждений в SP.

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

ПОЧТОВЫЙ / SAML2 / SSO / POST HTTP/1.1Хозяин: sp.example.comТип содержимого: приложение / x-www-form-urlencodedContent-Length: nnnSAMLResponse = ответ & RelayState = токен

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

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

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

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

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

 https://sp.example.com/myresource

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

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

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

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

Система единого входа в веб-браузере SAML 2.0 (POST)

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

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

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

 https://sp.example.com/myresource

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

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

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

  <форма метод="почтовый" действие="https://idp.example.org/SAML2/SSO/POST" ...>    <Вход тип="скрытый" имя=«SAMLRequest» ценить="запрос" />    <Вход тип="скрытый" имя="RelayState" ценить="токен" />    ...    <Вход тип="Разместить" ценить="Представлять на рассмотрение" />  </форма>

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 59Z"    AssertionConsumerServiceIndex ="0">    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>          AllowCreate ="истинный"      Формат ="urn: oasis: names: tc: SAML: 2.0: nameid-format: transient"/>  </samlp:AuthnRequest>

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

3. Запросите услугу единого входа в IdP.

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

ПОЧТОВЫЙ / SAML2 / SSO / POST HTTP/1.1Хозяин: idp.example.orgТип содержимого: приложение / x-www-form-urlencodedContent-Length: nnnSAMLRequest = запрос & RelayState = токен

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

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

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_2"    InResponseTo ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 22: 05Z"    Пункт назначения ="https://sp.example.com/SAML2/SSO/POST">    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>    <samlp:Status>              Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>    </samlp:Status>          xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"      ID ="идентификатор_3"      Версия ="2.0"      IssueInstant ="2004-12-05T09: 22: 05Z">      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>      <!-- a POSTed assertion MUST be signed -->              xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>      <saml:Subject>                  Формат ="urn: oasis: names: tc: SAML: 2.0: nameid-format: transient">          3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID>                  Метод ="урна: оазис: имена: tc: SAML: 2.0: cm: bearer">                      InResponseTo ="идентификатор_1"            Получатель ="https://sp.example.com/SAML2/SSO/POST"            NotOnOrAfter ="2004-12-05T09: 27: 05Z"/>        </saml:SubjectConfirmation>      </saml:Subject>              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>              AuthnInstant ="2004-12-05T09: 22: 00Z"        SessionIndex ="идентификатор_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. Запросить службу поддержки утверждений в SP.

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

ПОЧТОВЫЙ / SAML2 / SSO / POST HTTP/1.1Хозяин: sp.example.comТип содержимого: приложение / x-www-form-urlencodedContent-Length: nnnSAMLResponse = ответ & RelayState = токен

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

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

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

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

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

 https://sp.example.com/myresource

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

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

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

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

Система единого входа в веб-браузере SAML 2.0 (артефакт)

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

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

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

 https://sp.example.com/myresource

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

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

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

3. Запросите услугу единого входа в IdP.

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

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

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 58Z"    Пункт назначения ="https://sp.example.com/SAML2/ArtifactResolution">    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>    <!-- an ArtifactResolve message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Artifact>'артефакт_1'</samlp:Artifact>  </samlp:ArtifactResolve>

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    ID ="идентификатор_2"    InResponseTo ="идентификатор_1"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 21: 59Z">    <!-- an ArtifactResponse message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Status>              Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>    </samlp:Status>          xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"      xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"      ID ="идентификатор_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:Issuer>https://sp.example.com/SAML2</saml:Issuer>              AllowCreate ="ложный"        Формат ="urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress"/>    </samlp:AuthnRequest>  </samlp:ArtifactResponse>

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

6. Перенаправление в службу поддержки утверждений.

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

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

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

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

куда жетон значение токена из шага 3 и артефакт_2 артефакт SAML, выданный на шаге 6.

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    ID ="идентификатор_4"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 22: 04Z"    Пункт назначения ="https://idp.example.org/SAML2/ArtifactResolution">    <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>    <!-- an ArtifactResolve message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Artifact>'артефакт_2'</samlp:Artifact>  </samlp:ArtifactResolve>

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

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

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

      xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    ID ="идентификатор_5"    InResponseTo ="идентификатор_4"    Версия ="2.0"    IssueInstant ="2004-12-05T09: 22: 05Z">    <!-- an ArtifactResponse message SHOULD be signed -->          xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>    <samlp:Status>              Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>    </samlp:Status>          xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"      xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"      ID ="идентификатор_6"      InResponseTo ="идентификатор_3"      Версия ="2.0"      IssueInstant ="2004-12-05T09: 22: 05Z"      Пункт назначения ="https://sp.example.com/SAML2/SSO/Artifact">      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>              xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>      <samlp:Status>                  Значение ="urn: oasis: names: tc: SAML: 2.0: status: Success"/>      </samlp:Status>              xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"        ID ="идентификатор_7"        Версия ="2.0"        IssueInstant ="2004-12-05T09: 22: 05Z">        <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>        <!-- a Subject element is required -->        <saml:Subject>                      Формат ="urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress">            [email protected] </saml:NameID>                      Метод ="урна: оазис: имена: tc: SAML: 2.0: cm: bearer">                          InResponseTo ="идентификатор_3"              Получатель ="https://sp.example.com/SAML2/SSO/Artifact"              NotOnOrAfter ="2004-12-05T09: 27: 05Z"/>          </saml:SubjectConfirmation>        </saml:Subject>                  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>                  AuthnInstant ="2004-12-05T09: 22: 00Z"          SessionIndex ="идентификатор_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 домена это безопасный файл cookie браузера, относящийся к общему домену. Для каждого пользователя браузера этот файл cookie хранит список истории недавно посещенных IdP. Имя и значение файла cookie указаны в профиле обнаружения IdP (SAMLProf[3]).

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

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

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

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

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

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

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

      xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    xmlns: samlp ="урна: оазис: имена: tc: SAML: 2.0: протокол"    ID ="aaf23196-1773-2113-474a-fe114412ab72"    Версия ="2.0"    IssueInstant ="2006-07-17T20: 31: 40Z">          Формат ="urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName">      CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </saml:Issuer>    <saml:Subject>              Формат ="urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName">        CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </saml:NameID>    </saml:Subject>          NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"      Имя ="урна: oid: 2.5.4.42"      FriendlyName ="собственное имя">    </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 ="Почта">    </saml:Attribute>  </samlp:AttributeQuery>

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

      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>              Формат ="urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName">        CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </saml:NameID>              Метод ="урна: оазис: имена: tc: SAML: 2.0: cm: держатель ключа">        <saml:SubjectConfirmationData>          <ds:KeyInfo>            <ds:X509Data>              <!-- principal's X.509 cert -->              <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>    <!-- assertion lifetime constrained by principal's X.509 cert -->          NotBefore ="2006-07-17T20: 31: 41Z"      NotOnOrAfter ="2006-07-18T20: 21: 41Z">    </saml:Conditions>          AuthnInstant ="2006-07-17T20: 31: 41Z">      <saml:AuthnContext>        <saml:AuthnContextClassRef>            урна: оазис: имена: tc: SAML: 2.0: ac: classes: TLSClient </saml:AuthnContextClassRef>      </saml:AuthnContext>    </saml:AuthnStatement>    <saml:AttributeStatement>              xmlns: x500 ="урна: оазис: имена: tc: SAML: 2.0: профили: атрибут: X500"        x500: Кодировка ="LDAP"        NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"        Имя ="урна: oid: 2.5.4.42"        FriendlyName ="собственное имя">                  xsi: type ="xs: строка">Том</saml:AttributeValue>      </saml:Attribute>              xmlns: x500 ="урна: оазис: имена: tc: SAML: 2.0: профили: атрибут: X500"        x500: Кодировка ="LDAP"        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 ="Почта">                  xsi: type ="xs: строка">[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> элемент:

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

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

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

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

Метаданные службы единого входа

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

      protocolSupportEnumeration ="урна: оазис: имена: tc: SAML: 2.0: протокол">     использовать ="подписание">      <ds:KeyInfo>...</ds:KeyInfo>    </md:KeyDescriptor>     isDefault ="истинный" index ="0"      Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: SOAP"      Расположение ="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: временный</md:NameIDFormat>          Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect"      Расположение ="https://idp.example.org/SAML2/SSO/Redirect"/>          Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST"      Расположение ="https://idp.example.org/SAML2/SSO/POST"/>          Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact"      Расположение ="https://idp.example.org/SAML2/Artifact"/>          NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"      Имя ="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:Attribute>  </md:IDPSSODescriptor>

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

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

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

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

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

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

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

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

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

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

Потребительский сервис assertion содержится в <md:SPSSODescriptor> элемент:

      protocolSupportEnumeration ="урна: оазис: имена: tc: SAML: 2.0: протокол">     использовать ="подписание">      <ds:KeyInfo>...</ds:KeyInfo>    </md:KeyDescriptor>     использовать ="шифрование">      <ds:KeyInfo>...</ds:KeyInfo>    </md:KeyDescriptor>     isDefault ="истинный" index ="0"      Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: SOAP"      Расположение ="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: временный</md:NameIDFormat>     isDefault ="истинный" index ="0"      Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST"      Расположение ="https://sp.example.com/SAML2/SSO/POST"/>     index ="1"      Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact"      Расположение ="https://sp.example.com/SAML2/Artifact"/>     isDefault ="истинный" index ="1">       xml: lang ="en">Портал поставщика услуг</md:ServiceName>              NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"        Имя ="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. Для краткости ключевой материал опущен из ключевого дескриптора.
  • В индекс атрибут <md:AssertionConsumerService> элемент используется как значение AssertionConsumerServiceIndex атрибут в <samlp:AuthnRequest> элемент.
  • В Привязка атрибуты <md:AssertionConsumerService> элементы - это стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind[2]).
  • В Место расположения атрибут <md:AssertionConsumerService> элемент, поддерживающий привязку HTTP POST (index = "0") используется на шаге 4 "двойной POST "профиль.
  • В Место расположения атрибут <md:AssertionConsumerService> элемент, поддерживающий привязку HTTP-артефакта (index = "1") используется на шаге 6 "двойной артефакт "профиль.
  • В <md:AttributeConsumingService> используется поставщиком удостоверений для формулирования <saml:AttributeStatement> элемент, который передается поставщику услуг вместе с SSO веб-браузера.
  • В индекс атрибут <md:AttributeConsumingService> элемент используется как значение AttributeConsumingServiceIndex атрибут в <samlp:AuthnRequest> элемент.

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

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

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

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

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

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

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

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

Рекомендации

Первичные ссылки:

  1. ^ а б c S. Cantor et al. Утверждения и протоколы для языка разметки утверждений безопасности 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
  2. ^ а б c d е ж грамм S. Cantor et al. Привязки для языка разметки утверждений безопасности OASIS (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
  3. ^ а б c d е ж грамм J. Hughes et al. Профили для языка разметки утверждений безопасности OASIS (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
  4. ^ а б c d е S. Cantor et al. Метаданные для языка разметки утверждений безопасности OASIS (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

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

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

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

  • S. Cantor et al. Утверждения и протоколы для языка разметки утверждений безопасности 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