SAML 2.0

Язык разметки утверждений безопасности
Аббревиатура	SAML
Статус	Опубликовано
Год начался	ноябрь 2003 г.
Последняя версия	Версия 2.0 ; март 2005 г.
Предварительная версия	Версия 2.0 с исправлениями ; май 2019 г.
Организация	Организация по развитию стандартов структурированной информации (OASIS)
комитет	Технический комитет OASIS Security Services (SAML)
Веб-сайт	ОАЗИС 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] САМЛПроф, ^[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:Assertion
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75"
   Version="2.0"
   IssueInstant="2004-12-05T09:22:05Z">
   <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
   <ds:Signature
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <saml:Subject>
     <saml:NameID
       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
       3f7b3dcf-1674-4ecd-92c8-1544f346baf8
     </saml:NameID>
     <saml:SubjectConfirmation
       Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
       <saml:SubjectConfirmationData
         InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
         Recipient="https://sp.example.com/SAML2/SSO/POST"
         NotOnOrAfter="2004-12-05T09:27:05Z"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions
     NotBefore="2004-12-05T09:17:05Z"
     NotOnOrAfter="2004-12-05T09:27:05Z">
     <saml:AudienceRestriction>
       <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement
     AuthnInstant="2004-12-05T09:22:00Z"
     SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>
         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
       </saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute
       xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
       x500:Encoding="LDAP"
       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
       Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
       FriendlyName="eduPersonAffiliation">
       <saml:AttributeValue
         xsi:type="xs:string">member</saml:AttributeValue>
       <saml:AttributeValue
         xsi:type="xs:string">staff</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
 </saml:Assertion>

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

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

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

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

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

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

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

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

Протоколы SAML 2.0

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

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

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

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

В SAML 1.1 профили 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>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8=</samlp:Artifact>
  </samlp:ArtifactResolve>

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

Привязки SAML 2.0

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

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

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

HTTP-привязка POST

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

  <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
    <input type="hidden" name="SAMLRequest" value="''request''" />
    ... other input parameter....
  </form>

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

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

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

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

  window.onload = function () { document.forms[0].submit(); }

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

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

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

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact

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

  <samlp:ArtifactResponse
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="_d84a49e5958803dedcff4c984c2b0d95"
    InResponseTo="_cce4ee769ed970b501d680f697989d14"
    Version="2.0"
    IssueInstant="2004-12-05T09:21:59Z">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <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:bindings: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>

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

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

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

 SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact)
 TypeCode      := Byte1Byte2
 EndpointIndex := Byte1Byte2

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

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

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

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

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

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

 00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

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

Профили SAML 2.0

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

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

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

Профиль SSO веб-браузера

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

запрос на перенаправление SP; Ответ POST поставщика удостоверений

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

Единый вход через веб-браузер SAML 2.0 (привязка перенаправления SP/ответ POST IdP)

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

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

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

 https://sp.example.com/myresource

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

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

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

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

302 Redirect
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

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

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

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

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

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

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP/1.1
Host: idp.example.org

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

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

Служба единого входа проверяет запрос и отвечает документом, содержащим форму 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" />
  </form>

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

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
      <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. Запросите службу обработки утверждений у поставщика услуг.

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

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

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

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

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

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

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

 https://sp.example.com/myresource

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

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

SP POST-запрос; 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" />
  </form>

The 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-запрос службе единого входа у провайдера удостоверений:

POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn

SAMLRequest=request&RelayState=token

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

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

Служба единого входа проверяет запрос и отвечает документом, содержащим форму 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" />
  </form>

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

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <!-- a POSTed assertion MUST be signed -->
      <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. Запросите службу обработки утверждений у поставщика услуг.

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

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

где значения 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.

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

 https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact_1&RelayState=token

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

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

Служба единого входа разыменовывает артефакт, отправляя <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>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>''artifact_1''</samlp:Artifact>
  </samlp:ArtifactResolve>

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

5. Ответьте SAML AuthnRequest.

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

  <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">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:AuthnRequest
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_3"
      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:bindings: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>

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

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

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

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

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

 https://sp.example.com/SAML2/SSO/Artifact?SAMLart=artifact_2&RelayState=token

где 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>
    <!-- an ArtifactResolve message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Artifact>''artifact_2''</samlp:Artifact>
  </samlp:ArtifactResolve>

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

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

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

  <samlp:ArtifactResponse
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="identifier_5"
    InResponseTo="identifier_4"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z">
    <!-- an ArtifactResponse message SHOULD be signed -->
    <ds:Signature
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <samlp:Response
      xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      ID="identifier_6"
      InResponseTo="identifier_3"
      Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z"
      Destination="https://sp.example.com/SAML2/SSO/Artifact">
      <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
      <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
      <samlp:Status>
        <samlp:StatusCode
          Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
      </samlp:Status>
      <saml:Assertion
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        ID="identifier_7"
        Version="2.0"
        IssueInstant="2004-12-05T09:22:05Z">
        <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
        <!-- a Subject element is required -->
        <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. Снова запросите целевой ресурс у SP.

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

 https://sp.example.com/myresource

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

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

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

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

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

В качестве гипотетического примера Common Domain предположим, что 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> элемент, который используется для запроса утверждения по его уникальному идентификатору ( 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">
      [email protected],OU=User,O=NCSA-TEST,C=US
    </saml:Issuer>
    <saml:Subject>
      <saml:NameID
        Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
        [email protected],OU=User,O=NCSA-TEST,C=US
      </saml:NameID>
    </saml: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">
        [email protected],OU=User,O=NCSA-TEST,C=US
      </saml:NameID>
      <saml:SubjectConfirmation
        Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">
        <saml:SubjectConfirmationData>
          <ds:KeyInfo>
            <ds:X509Data>
              <!-- 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 -->
    <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>
            urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute
        xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
        x500:Encoding="LDAP"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="urn:oid:2.5.4.42"
        FriendlyName="givenName">
        <saml:AttributeValue
          xsi:type="xs:string">Tom</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute
        xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
        x500:Encoding="LDAP"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
        FriendlyName="mail">
        <saml:AttributeValue
          xsi:type="xs:string">[email protected]</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>

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

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

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

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

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

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

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

  <md:EntityDescriptor entityID="https://idp.example.org/SAML2" validUntil="2013-03-22T23:00:00Z"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- insert ds:Signature element (omitted) -->
    <!-- insert md:IDPSSODescriptor element (below) -->
    <md:Organization>
      <md:OrganizationName xml:lang="en">Some Non-profit Organization of New York</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Some Non-profit Organization</md:OrganizationDisplayName>
      <md:OrganizationURL xml:lang="en">https://www.example.org/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
      <md:SurName>SAML Technical Support</md:SurName>
      <md:EmailAddress>mailto:[email protected]</md:EmailAddress>
    </md:ContactPerson>
  </md:EntityDescriptor>

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

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

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

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

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

  <md:IDPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
      Location="https://idp.example.org/SAML2/ArtifactResolution"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:SingleSignOnService
      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>member</saml:AttributeValue>
      <saml:AttributeValue>student</saml:AttributeValue>
      <saml:AttributeValue>faculty</saml:AttributeValue>
      <saml:AttributeValue>employee</saml:AttributeValue>
      <saml:AttributeValue>staff</saml:AttributeValue>
    </saml:Attribute>
  </md:IDPSSODescriptor>

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

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

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

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

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

  <md:EntityDescriptor entityID="https://sp.example.com/SAML2" validUntil="2013-03-22T23:00:00Z"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- insert ds:Signature element (omitted) -->
    <!-- insert md:SPSSODescriptor element (see below) -->
    <md:Organization>
      <md:OrganizationName xml:lang="en">Some Commercial Vendor of California</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Some Commercial Vendor</md:OrganizationDisplayName>
      <md:OrganizationURL xml:lang="en">https://www.example.com/</md:OrganizationURL>
    </md:Organization>
    <md:ContactPerson contactType="technical">
      <md:SurName>SAML Technical Support</md:SurName>
      <md:EmailAddress>mailto:[email protected]</md:EmailAddress>
    </md:ContactPerson>
  </md:EntityDescriptor>

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

The entityID Атрибут — уникальный идентификатор сущности.
The validUntil Атрибут указывает дату истечения срока действия метаданных.
The <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="signing">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="encryption">
      <ds:KeyInfo>...</ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
      Location="https://sp.example.com/SAML2/ArtifactResolution"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:AssertionConsumerService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://sp.example.com/SAML2/SSO/POST"/>
    <md:AssertionConsumerService index="1"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      Location="https://sp.example.com/SAML2/Artifact"/>
    <md:AttributeConsumingService isDefault="true" index="1">
      <md:ServiceName xml:lang="en">Service Provider Portal</md:ServiceName>
      <md:RequestedAttribute
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
        FriendlyName="eduPersonAffiliation">
      </md:RequestedAttribute>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>

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

Программное обеспечение поставщика услуг настроено с использованием частного ключа подписи SAML и/или частного ключа TLS обратного канала. Соответствующий открытый ключ включен в <md:KeyDescriptor use="signing"> элемент в метаданных SP. Ключевой материал был опущен в ключевом дескрипторе для краткости.
Аналогично, программное обеспечение поставщика услуг настроено с использованием частного ключа дешифрования SAML. Открытый ключ шифрования SAML включен в комплект поставки. <md:KeyDescriptor use="encryption"> элемент в метаданных SP. Ключевой материал был опущен в ключевом дескрипторе для краткости.
The index атрибут <md:AssertionConsumerService> элемент используется в качестве значения AssertionConsumerServiceIndex атрибут в <samlp:AuthnRequest> элемент.
The Binding атрибуты <md:AssertionConsumerService> элементы представляют собой стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind ^[2]).
The Location атрибут <md:AssertionConsumerService> элемент, поддерживающий привязку HTTP POST ( index="0") используется на шаге 4 профиля « double POST ».
The Location атрибут <md:AssertionConsumerService> элемент, который поддерживает привязку HTTP-артефакта ( index="1") используется на шаге 6 профиля « двойной артефакт ».
The <md:AttributeConsumingService> элемент используется поставщиком удостоверений для формирования <saml:AttributeStatement> элемент, который передается поставщику услуг вместе с SSO веб-браузера.
The 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#">
    <!-- insert ds:Signature element (omitted) -->
    <md:EntityDescriptor entityID="https://idp.example.org/SAML2">
      ...
    </md:EntityDescriptor>
    <md:EntityDescriptor entityID="https://sp.example.com/SAML2">
      ...
    </md:EntityDescriptor>
  </md:EntitiesDescriptor>

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

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

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

Сопутствующие товары

Folio (формально известный как FOLIO, от латинского «лист») — это облачная платформа с открытым исходным кодом для управления библиотекой, разработанная международным сообществом Folio. Folio разрабатывается с 2015 года компанией-разработчиком программного обеспечения Index Data при финансовой поддержке EBSCO Information Services. Исполняемая программная основа доступна с сентября 2016 года, а начальная версия с функциональными модулями выпущена в 2018 году. ^[5]^[6]^[7]^[8]

См. также

Ссылки

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

^ Перейти обратно: ^а ^б ^с С. Кантор и др. Утверждения и протоколы для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г С. Кантор и др. Привязки для языка разметки утверждений безопасности 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
^ Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г Дж. Хьюз и др. Профили для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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
^ Перейти обратно: ^а ^б ^с ^д ^и С. Кантор и др. Метаданные для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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
^ «ФОЛИО – новое сотрудничество между библиотеками, поставщиками услуг и разработчиками» . битонлайн . 28 июня 2016 г. Проверено 15 июля 2016 г.
^ «Репозитории уже здесь — выпущены репозитории исходного кода FOLIO» . folio.org . 27 сентября 2016 г. Проверено 28 сентября 2016 г.
^ Нассиб Нассар (01 сентября 2016 г.). «ФОЛИО Девелопер» . dev.folio.org . Проверено 6 октября 2016 г.
^ Нассиб Нассар (01 сентября 2016 г.). «ФОЛИО Девелопер» . dev.folio.org . Проверено 6 октября 2016 г.

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

П. Мишра и др. Требования соответствия для языка разметки утверждений безопасности OASIS (SAML) V2.0 — Errata Composite. Рабочий проект 04, 1 декабря 2009 г. Идентификатор документа sstc-saml-conformance-errata-2.0-wd-04 https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata -2.0-wd-04-diff.pdf

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

П. Мэдсен и др., Обзор 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- обзор-2.0-cd-01-2col.pdf

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

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

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

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

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

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

С. Кантор и др. Привязки для языка разметки утверждений безопасности 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

С. Кантор и др. Профили для языка разметки утверждений безопасности 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

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

[SAMLCore-1] Перейти обратно: ^а ^б ^с С. Кантор и др. Утверждения и протоколы для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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

[SAMLBind-2] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г С. Кантор и др. Привязки для языка разметки утверждений безопасности 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

[SAMLProf-3] Перейти обратно: ^а ^б ^с ^д ^и ^ж ^г Дж. Хьюз и др. Профили для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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

[SAMLMeta-4] Перейти обратно: ^а ^б ^с ^д ^и С. Кантор и др. Метаданные для языка разметки утверждений безопасности OASIS (SAML) V2.0 — составной набор ошибок. Рабочий проект 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

[bit-2016-06-5] «ФОЛИО – новое сотрудничество между библиотеками, поставщиками услуг и разработчиками» . битонлайн . 28 июня 2016 г. Проверено 15 июля 2016 г.

[repositories-released-6] «Репозитории уже здесь — выпущены репозитории исходного кода FOLIO» . folio.org . 27 сентября 2016 г. Проверено 28 сентября 2016 г.

[librarysystem-7] Нассиб Нассар (01 сентября 2016 г.). «ФОЛИО Девелопер» . dev.folio.org . Проверено 6 октября 2016 г.

[librarysystem-github-8] Нассиб Нассар (01 сентября 2016 г.). «ФОЛИО Девелопер» . dev.folio.org . Проверено 6 октября 2016 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]