Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Язык разметки утверждения безопасности
Положение делОпубликовано
Год началсяНоябрь 2003 г.
Последняя версияВерсия 2.0,
март 2005 г.
Предварительная версияВерсия 2.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 был ратифицирован в качестве стандарта 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 является так называемое утверждение «носителя», используемое для упрощения единого входа в веб-браузере. Вот пример недолговечного утверждения носителя, выданного поставщиком удостоверений (https://idp.example.org/SAML2) поставщику услуг (https://sp.example.com/SAML2). Утверждение включает в себя как утверждение аутентификации, так и утверждение <saml:AuthnStatement>атрибута <saml:AttributeStatement>, которые предположительно использует поставщик услуг для принятия решения о контроле доступа. Префикс saml:представляет пространство имен утверждения SAML V2.0.

Пример SAML [ править ]

<SAML: Утверждающие  XMLNS: SAML = "урна: оазис: имена: TC: SAML: 2.0:" Утверждающие  Xmlns: хз = "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- формат: переходный " > 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:Аудитория>  </ 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 " >персонал </ 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 профили SSO веб-браузера инициируются поставщиком удостоверений (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: Signature>  <samlp: Artifact>AAQAAMh48 / 1oXIM + sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8 = </ samlp: Artifact>  </ samlp: ArtifactResolve>

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

Привязки SAML 2.0 [ править ]

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

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

Для единого входа в веб-браузере обычно используются привязка перенаправления 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 ib% 2FCon% 2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9% 2FfCR7GorYGTWFK8pu6DknnwKL% 2FWEetlxmR8s BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz% 2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2% 2FBK5MNo1F dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0% 2Bin8xutxYOvZL18NK UqPlvZR5el% 2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P% 2FAXv4C

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

Привязка HTTP POST [ править ]

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

 < form  method = "post"  action = "https://idp.example.org/SAML2/SSO/POST"  ... >  < input  type = "hidden"  name = "SAMLRequest"  value = "'' request '' "  /> ... другой входной параметр .... </ форма >

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

 < form  method = "post"  action = "https://sp.example.com/SAML2/SSO/POST"  ... >  < input  type = "hidden"  name = "SAMLResponse"  value = "'' response '' "  /> ... </ форма >

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

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

 окно . onload  =  function  ()  {  документ . формы [ 0 ]. submit ();  }

Это, конечно, предполагает, что первый элемент формы на странице содержит указанный выше SAMLResponse, содержащий formelement ( forms[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>сообщение:

 <samlp: ArtifactResponse  xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol"  ID = "_d84a49e5958803dedcff4c984c2b0d95"  InResponseTo = "_cce4ee769ed970b501d614d09-05:"  Версия для печати "  Issue 4 : 0" " >  <! - сообщение 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"  Version = "2.0"  IssueInstant = "2004-12 -05T09: 21: 59Z "  Destination = " https://idp.example.org/SAML2/SSO/Artifact "  ProtocolBinding = " urn: oasis: names: tc: SAML: 2.0: привязки: HTTP-Artifact "  AssertionConsumerServiceURL = " https://sp.example.com/SAML2/SSO/Artifact " >  <saml: Issuer> https://sp.example.com/SAML2 </ saml: Issuer>  <samlp: NameIDPolicy  AllowCreate = " false "  Формат = "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 состоит из трех компонентов: двухбайтовой TypeCode, двухбайтовой EndpointIndexи произвольной последовательности байтов, называемой RemainingArtifact. Эти три части информации объединяются и кодируются в кодировке base64, чтобы получить полный артефакт.

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

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

 TypeCode: = 0x0004 RemainingArtifact: = SourceId MessageHandle SourceId: = 20-байтовая_последовательность MessageHandle: = 20-байтовая_последовательность

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

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

 00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

Если вы присмотритесь, вы увидите TypeCode(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, как это предлагается в следующем исчерпывающем списке профилей:

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

Хотя количество поддерживаемых профилей довольно велико, спецификация профилей (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параметра - это дефлированное значение <samlp:AuthnRequest>элемента в кодировке base64 и URL :

 <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. Запросите услугу единого входа в IdP.

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

GET  / SAML2 / SSO / Redirect? SAMLRequest = запрос & RelayState = токен  HTTP / 1.1 Хост :  idp.example.org

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

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

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

 < form  method = "post"  action = "https://sp.example.com/SAML2/SSO/POST"  ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /></ форма >

Значение 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 :Утверждение  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>  <! - a POSTED утверждение ДОЛЖНО быть подписано ->  <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. Запросить службу поддержки утверждений в SP.

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

POST  / SAML2 / SSO / POST  HTTP / 1.1 Хост :  sp.example.com Content-Type :  application / x-www-form-urlencoded Content-Length :  nnn SAMLResponse = response & RelayState = token

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

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

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

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

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

 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:

 < form  method = "post"  action = "https://idp.example.org/SAML2/SSO/POST"  ... > < input type = "hidden" name = "SAMLRequest" value = "request" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /></ форма >

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. Запросите услугу единого входа в IdP.

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

POST  / SAML2 / SSO / POST  HTTP / 1.1 Хост :  idp.example.org Content-Type :  application / x-www-form-urlencoded Content-Length :  nnnSAMLRequest = запрос & RelayState = токен

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

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

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

 < form  method = "post"  action = "https://sp.example.com/SAML2/SSO/POST"  ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /></ форма >

Значение 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 :Утверждение  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>  <! - a POSTED утверждение ДОЛЖНО быть подписано ->  <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. Запросить службу поддержки утверждений в SP.

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

POST  / SAML2 / SSO / POST  HTTP / 1.1 Хост :  sp.example.com Content-Type :  application / x-www-form-urlencoded Content-Length :  nnn SAMLResponse = response & RelayState = token

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

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

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

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

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

 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= artifact_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>'' артефакт_1 '' </ samlp: Артефакт> </ 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: протокол"  xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"  ID = "identifier_3"  Version = "2.0"  IssueInstant = "2004-12-05T09: 21: 59Z"  Destination = "https://idp.example.org / SAML2 / SSO / Artifact "  ProtocolBinding = " urn: oasis: names: tc: SAML: 2.0: привязки: HTTP-Artifact "  AssertionConsumerServiceURL = " https://sp.example.com/SAML2/SSO/Artifact " >  <saml : Issuer> https://sp.example.com/SAML2 </ saml: Issuer>  <samlp: NameIDPolicy  AllowCreate = "false"  Format = "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= artifact_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>'' артефакт_2 '' </ samlp: Артефакт> </ 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: протокол"  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: утверждение  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: 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_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. Запросите целевой ресурс у поставщика услуг еще раз.

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

 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 хранит список истории недавно посещенных IdP. Имя и значение файла cookie указаны в профиле обнаружения IdP (SAMLProf [3] ).

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

Запрос подтверждения / профиль запроса [ править ]

Assertion Query / Запрос профиль является общим профилем , который вмещает множество типов так называемые запросы , используя следующие элементы 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 "  Version = " 2.0 "  IssueInstant = " 2006-07-17T20: 31: 40Z " >  <saml: Issuer  Format = " urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName " > CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </ saml: Issuer>  <saml: Subject>  <saml: NameID  Format = "urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName" > CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </ saml: NameID>  </ saml: Subject>  <saml: Attribute  NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"  Name = "urn: oid: 2.5.4.42"  FriendlyName = "givenName" >  </ saml: Attribute>  <saml: Attribute  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: Attribute>  </ samlp: AttributeQuery>

Обратите внимание , что Issuerэто Subjectв данном случае. Иногда это называют самозапросом атрибута . Провайдер идентификации может вернуть следующее утверждение, заключенное в <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 "  Version = " 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 " > CN = trscavo @ uiuc.edu, OU = Пользователь, O = NCSA-TEST, C = США </ 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: Conditions>  <saml: AuthnStatement  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>  <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:профили: атрибут: 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: метаданные "  xmlns: saml = " urn: oasis: names: tc: SAML: 2.0: assertion "  xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " >  <! - вставить ds: Элемент подписи (опущен) ->  <! - вставьте элемент 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]

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

Метаданные службы единого входа [ править ]

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

 <md: IDPSSODescriptor  protocolSupportEnumeration = "urn: oasis: names: tc: SAML: 2.0: protocol" >  <md: KeyDescriptor  use = "подписывание" >  <ds: KeyInfo> ... </ ds: KeyInfo>  </ md: KeyDescriptor>  <md: ArtifactResolutionService  isDefault = "true"  index = "0"  Binding = "urn: oasis: names: tc: SAML: 2.0: привязки: 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: временный</ md: NameIDFormat>  <md: SingleSignOnService  Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect"  Location = "https://idp.example.org/SAML2/SSO/Redirect" />  <md: SingleSignOnService  Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST"  Location = "https://idp.example.org/SAML2/SSO/POST" />  <md : SingleSignOnService  Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact"  Location = "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> Staff </ saml: AttributeValue>  </ saml: Attribute>  </ md: IDPSSODescriptor>

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

  • Программное обеспечение поставщика удостоверений настроено с использованием закрытого ключа подписи 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 , указанные в спецификации Binding SAML 2.0 (SAMLBind [2] ).
  • LocationАтрибут <md:SingleSignOnService>элемента , который поддерживает привязку HTTP - POST используется в шаге 2 « двойной пост » профиль.
  • 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: метаданные "  xmlns: saml = " urn: oasis: names: tc: SAML: 2.0: assertion "  xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " >  <! - вставить ds: Элемент подписи (опущен) ->  <! - вставить элемент md: SPSSODescriptor (см. Ниже) ->  <md: Organization>  <md: OrganizationName  xml: lang = "en" > Некоторые коммерческие поставщики из Калифорнии </ md: OrganizationName>  <md: OrganizationDisplayName  xml: lang = "ru " > Некоторые коммерческие поставщики</ 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]

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

Метаданные клиентской службы утверждения [ править ]

Служба потребителя утверждения содержится в <md:SPSSODescriptor>элементе:

 <md: SPSSODescriptor  protocolSupportEnumeration = "urn: oasis: names: tc: SAML: 2.0: protocol" >  <md: KeyDescriptor  use = "подписывание" >  <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 / Артефакт " />  <md:AttributeConsumingService  isDefault = "true" index = "1" >  <md: ServiceName  xml: lang = "ru" > Портал поставщика услуг </ md: ServiceName>  <md: RequestedAttribute  NameFormat = "urn: oasis: names: tc: SAML: 2.0: формат-атрибута: 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 , указанные в спецификации Binding SAML 2.0 (SAMLBind [2] ).
  • LocationАтрибут <md:AssertionConsumerService>элемента , который поддерживает HTTP POST связывания ( index="0") используется на этапе 4 « двойной 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>элементе:

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

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

См. Также [ править ]

  • Язык разметки утверждения безопасности
  • SAML 1.1
  • Метаданные SAML
  • Продукты и услуги на основе SAML
  • OpenID Connect

Ссылки [ править ]

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

  1. ^ а б в С. Кантор и др. Утверждения и протоколы для языка разметки утверждений безопасности 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. ^ Б с д е е г S. Cantor и др. Привязки для языка разметки утверждений безопасности 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. ^ Б с д е е г J. Hughes и др. Профили для языка разметки утверждений безопасности 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. ^ a b c d e 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

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

  • P. Mishra et al. Требования соответствия для языка разметки утверждений безопасности OASIS (SAML) V2.0 - Errata Composite. Рабочий проект 04, 1 декабря 2009 г. Идентификатор документа sstc-saml-Complance-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
  • П. Мэдсен и др., Обзор SAML V2.0. Проект комитета 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
  • 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
  • J. Hodges et al. Глоссарий языка разметки утверждений безопасности 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-compliance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-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
  • S. Cantor et al. Привязки для языка разметки утверждений безопасности 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 et al. Профили для языка разметки утверждений безопасности 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 et al. Метаданные для языка разметки утверждений безопасности 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