Метаданные SAML

Стандарт метаданных SAML принадлежит к семейству стандартов на основе XML, известных как язык разметки утверждений безопасности (SAML), опубликованных OASIS в 2005 году. Документ метаданных SAML описывает развертывание SAML, например поставщик удостоверений SAML или поставщик услуг SAML . При развертывании используются общие метаданные для установления базового уровня доверия и совместимости.

Обзор

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

• Идентификатор объекта
• Криптографические ключи
• Конечные точки протокола (привязки и местоположения)

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

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

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

Предыдущий сценарий требует, чтобы каждая сторона заранее знала другую. Чтобы установить базовый уровень доверия, стороны делятся друг с другом метаданными. Первоначально это может быть так же просто, как обмен информацией по электронной почте. Со временем, по мере роста числа партнеров SAML, естественной тенденцией становится автоматизация процесса обмена метаданными.

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

Функциональная совместимость на основе метаданных

По мере развития технологии SAML важность метаданных SAML неуклонно растет. Сегодня для реализации, поддерживающей единый вход в веб-браузер SAML, требуется файл метаданных SAML с допустимой схемой для каждого партнера SAML. (См. профили SAML V2.0. спецификацию для получения дополнительной информации о системе единого входа веб-браузера SAML.)

Единый вход в веб-браузере SAML со статической конфигурацией метаданных

Статическая конфигурация метаданных

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

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

Теперь предположим, что метаданные SP содержат общедоступный ключ шифрования. Предположительно, соответствующий закрытый ключ дешифрования настроен в программном обеспечении SP. Если частный ключ дешифрования скомпрометирован (или его необходимо заменить по другой причине), общедоступный ключ шифрования в метаданных SP больше не заслуживает доверия и его также необходимо заменить.

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

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

Единый вход через веб-браузер SAML с автоматическим обменом метаданными

Динамический обмен метаданными

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

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

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

История

Дополнительная информация: Язык разметки утверждений безопасности § История.

Теперь давайте проследим некоторые шаги, которые привели к публикации спецификации метаданных SAML V2.0 в марте 2005 года. Поворотный момент произошел 14 ноября 2003 года — с этого начинается наша история.

Историческое происхождение

В ответ на Microsoft Passport Liberty Alliance задумал Identity Federation Framework , технологию федерации, разрабатывавшуюся в течение трехлетнего периода с 2002 по 2004 год. (Упомянутая ранее история SAML обеспечивает контекст для ID-FF.) 14 ноября 2003 г. Liberty предоставила ID-FF 1.2 для OASIS . Вклад включал документ под названием « Описание метаданных Liberty и спецификация обнаружения», версия 1.0. который включал следующие цели проектирования:

1. «whois для федераций SAML» (на основе Organization и ContactPerson элементы в метаданных)
2. динамическое обнаружение метаданных (с разрешением через DNS и общеизвестное местоположение)
3. безопасность на уровне документа с использованием XML-подписи

Как оказалось, все эти цели были сохранены в стандарте метаданных OASIS SAML V2.0, описанном ниже в этой статье.

Документ схемы, включенный в устаревший архив Liberty ID-FF 1.2, идентифицируется как метаданные Liberty версии 1.1, тогда как метаданные Liberty версии 1.0 были предоставлены OASIS. Кажущееся противоречие объяснил автор схемы. (Питер Дэвис, личное общение) С ноября 2003 г. (когда версия 1.0 была добавлена ​​в OASIS) по декабрь 2004 г. (когда Liberty завершила работу над версией 1.1) разработка спецификации метаданных Liberty продолжалась параллельно с рабочим потоком OASIS. См. диаграмму ниже для визуального представления. Стрелки на диаграмме указывают зависимости, а пунктирные линии — эквивалентность.

Зависимости метаданных SAML

Соответствующие ссылки на рабочий поток Liberty приведены в конце этой статьи. Исходная схема метаданных, предоставленная OASIS, полностью указана в разделе 7 метаданных Liberty версии 1.0. спецификация. Аналогично, спецификация метаданных Liberty версии 1.1 включает листинг схемы версии 1.1. Ссылки на схему версии 1.0 и схему версии 1.1 предоставлены Wayback Machine Интернет-архива.

Пост-ноябрь 2003 г.

В течение следующих тринадцати месяцев, с ноября 2003 г. по декабрь 2004 г., Технический комитет OASIS Security Services (SAML) (SSTC) превратил спецификацию метаданных Liberty в то, что в конечном итоге стало известно как метаданные SAML. За это время SSTC обобщил спецификацию метаданных, включив в нее поддержку нескольких протоколов (включая протоколы, не относящиеся к SAML), но, что более важно, схема метаданных Liberty была дополнена многочисленными точками расширения. Исторически, как мы увидим, расширяемость метаданных SAML имела важные последствия.

К марту 2004 года большая часть вклада Liberty была включена в рабочий поток OASIS. С этого момента рабочие направления Liberty и OASIS развивались одновременно (но не независимо, поскольку над обеими спецификациями работали одни и те же люди). В период с марта по июль 2004 г. молодая спецификация метаданных SAML претерпела значительные изменения.

В июле 2004 года SSTC опубликовал публичный запрос комментариев по полному набору проектов спецификаций SAML V2.0. В этот набор спецификаций был включен рабочий проект недавно созданной спецификации метаданных SAML V2.0.

Оглядываясь назад, можно сказать, что основная часть спецификации метаданных SAML V2.0 была разработана в период с марта по июль 2004 года, но очевидно, что стандарт метаданных SAML V2.0 возник из чресл Liberty Alliance, в частности, Liberty Metadata Version 1.0. Следовательно, чтобы понять происхождение метаданных SAML, необходимо изучить происхождение метаданных Liberty.

Оставшаяся история метаданных SAML — это в основном административный процесс OASIS. После того как окончательный проект Комитета был опубликован в ноябре 2004 г., SSTC начал процесс стандартизации в январе 2005 года. Наконец, 5 марта 2005 года OASIS объявил о новом ратифицированном стандарте SAML V2.0.

Набор спецификаций V2.0 (полный список см. в разделе «Ссылки ») включал окончательную спецификацию метаданных SAML V2.0. Десять лет спустя, в сентябре 2015 года, OASIS опубликовал пересмотренную спецификацию метаданных SAML с ошибками. В результате исходная спецификация метаданных была признана устаревшей, как и другие документы в исходном наборе спецификаций 2.0.

За прошедшее десятилетие, с 2005 по 2015 год, SSTC разработал ряд проектов спецификаций «Post-V2.0». Некоторые из этих проектов документов стали Спецификациями Комитета. Отдельные части этих спецификаций комитета перечислены в разделе «Ссылки» в конце этой статьи.

До ноября 2003 г.

Как выяснилось, влияние Liberty Identity Federation Framework на метаданные SAML предшествовало появлению ID-FF 1.2 в ноябре 2003 года. Судя по всему, SSTC баловался метаданными параллельно с Liberty Alliance. Об этом свидетельствует выдержка из проекта спецификации метаданных, опубликованного в сентябре 2003 года:

В этом документе определяются метаданные, описывающие элементы и атрибуты, необходимые для использования профилей SSO веб-браузера SAML. Поскольку профили единого входа Liberty Alliance Web напрямую основаны на профилях единого входа SAML Web, метаданные, определенные в этом документе, во многом заимствованы из определений метаданных в проекте спецификаций Liberty Alliance 1.2. (Извлечено из «Метаданных для профилей SSO веб-браузера SAML 2.0»). )

История изменений в конце этого проекта документа дает следующую характеристику: «Первоначальный проект основан на проекте 07 спецификации метаданных SAML 1.1». То есть ранее были опубликованы проекты документов. Действительно, история изменений в конце предыдущего черновика показывает список спецификаций метаданных, начиная с ноября 2002 года.

Если проследить за документом, влияние Liberty ID-FF на метаданные SAML можно проследить до проекта спецификации, опубликованного в апреле 2003 года. Это первый известный документ OASIS, в котором упоминается Liberty ID-FF, в частности, метаданные Liberty версии 1.0-06. ранняя версия спецификации метаданных Liberty, о которой мало что известно. Однако ясно, что «Метаданные для профилей веб-браузера SAML 1.1» были задуманы как дополнение к стандарту SAML V1.1, но, конечно, мы знаем, что V1.1 не определяет использование метаданных. Соответствующую гипотезу смотрите в следующем разделе.

Две ранние схемы метаданных могут представлять интерес:

1. В июне 2002 года, всего через месяц после того, как SSTC завершил работу над тем, что впоследствии стало стандартом SAML V1.0, проект Shibboleth разработал схему метаданных, состоящую из <OriginSite> и <DestinationSite> элементы. Эта схема будет использоваться в первых версиях программного обеспечения Shibboleth IdP.
2. В феврале 2003 года SSTC опубликовал проект схемы спецификации метаданных под названием «Метаданные для профилей веб-браузера SAML 1.0». Однако эта схема остается любопытной, поскольку уже в следующей версии этого потока документов (и всех последующих версиях) будет использоваться синтаксис метаданных Liberty.

Нет никаких доказательств того, что какая-либо из этих ранних попыток определить схему метаданных оказала какое-либо заметное влияние на развитие схемы метаданных Liberty.

Историческое резюме

Мы знаем, что стандарты метаданных для SAML V1.0 или SAML V1.1 никогда не публиковались. Мы также знаем, что необходимые права интеллектуальной собственности на метаданные Liberty не существовали до ноября 2003 года. При этом мы предлагаем следующее резюме и предположение:

1. Проект спецификации под названием «Метаданные для профилей веб-браузера SAML 1.0». была первой известной спецификацией метаданных SAML. Документ датирован 12 ноября 2002 года, то есть через неделю после анонса стандарта SAML V1.0, что любопытно. В любом случае синтаксис метаданных, используемый в этом документе, полностью отличается от того, что мы сейчас знаем как метаданные SAML. Этот документ так и не был опубликован, и его происхождение остается загадкой.
2. Проект спецификации под названием «Метаданные для профилей веб-браузера SAML 1.1». была первой известной спецификацией метаданных SAML, основанной на Liberty ID-FF. Он был завершен в апреле 2003 года. Название проекта спецификации ясно дает понять, что SSTC знал о появлении SAML V1.1 и, более того, метаданные SAML должны были быть включены в стандарт SAML V1.1.
3. К сожалению, этого не произошло, поскольку на момент анонса стандарта SAML V1.1 не было необходимых прав на интеллектуальную собственность. Действительно, официальное внедрение Liberty ID-FF 1.2 в OASIS произошло через два месяца после анонса стандарта SAML V1.1 в сентябре 2003 года.
4. В сентябре 2003 года, менее чем через две недели после объявления стандарта SAML V1.1, SSTC нацелился на SAML V2.0, разделив поток документов и переименовав проект документа: «Метаданные для профилей веб-браузера SAML 2.0».
5. Метаданные SAML появились в период с марта по июль 2004 года. SSTC опубликовал публичный запрос на комментарии , которые включали кандидатскую спецификацию метаданных SAML.
6. Окончательная спецификация метаданных SAML был включен в набор спецификаций стандарта SAML V2.0, объявленный в марте 2005 года.
7. В течение следующих 10 лет документы спецификации развивались (но схема оставалась стабильной). Спецификация метаданных SAML V2.0 с ошибками (SAMLMeta20Errata ) был опубликован в сентябре 2015 года.

Спецификации после версии 2.0

Как упоминалось ранее, схема метаданных SAML V2.0 имеет множество точек расширения. Эта функция привела к распространению спецификаций Post-V2.0, которые расширили стандарт в нескольких направлениях. Наиболее популярные расширения метаданных для удобства перечислены ниже (см. примеры для конкретных случаев использования):

1. Расширения метаданных SAML V2.0 для регистрации и информации о публикации, версия 1.0.
2. Расширение метаданных SAML V2.0 для атрибутов объектов.
3. Расширения метаданных SAML V2.0 для пользовательского интерфейса входа и обнаружения версии 1.0.
4. Протокол и профиль службы обнаружения поставщика удостоверений.
5. Протокол и профиль инициирования запроса поставщика услуг версии 1.0.
6. Профиль метаданных SAML V2.0 для поддержки алгоритмов версии 1.0.

Важной спецификацией «Post-V2.0» является профиль совместимости метаданных SAML V2.0, который основан на предпосылке, что формальная инфраструктура открытых ключей (PKI) может быть чрезвычайно сложной и в некоторых случаях трудноразрешимой (хорошо известно, например, что отзыв сертификата TLS, доступный браузеру, не работает ). По сути, профиль совместимости метаданных — это попытка предоставить работоспособный механизм отзыва ключей для федераций SAML.

С момента публикации в августе 2009 года Профиль совместимости метаданных стал особенно влиятельным документом, особенно в сфере высшего образования (см., например, требования к сертификатам для специалистов по развертыванию). в одной крупной федерации исследований и разработок). Совместимость метаданных играет ключевую роль в официальном профиле реализации, опубликованном Kantara Initiative:

Реализации ДОЛЖНЫ поддерживать интерпретацию и применение метаданных, как определено профилем совместимости метаданных SAML V2.0. Отсюда следует, что реализации ДОЛЖНЫ быть способны взаимодействовать (что приводит к успеху или неудаче в зависимости от конфигурации по умолчанию) с любым количеством одноранговых узлов SAML, для которых доступны метаданные, без дополнительных входных данных или отдельной настройки.

Действительно, ключевой особенностью, которая отличает масштабируемую реализацию SAML (от другой), является совместимость метаданных.

Примеры метаданных SAML

В этом разделе мы приводим конкретные примеры дескриптора объекта SAML , базовой единицы политики и взаимодействия в метаданных SAML. Каждый из примеров включает следующие биты метаданных:

• Идентификатор объекта и атрибуты объекта
• Дескриптор роли (описывающий либо поставщика удостоверений SAML , либо поставщика услуг SAML )
  • Элементы пользовательского интерфейса
  • Ключи подписи или ключи шифрования
  • Конечные точки протокола единого входа
• Информация о регистрации и публикации
• Организация и контактная информация (для читателей)

В приведенных ниже примерах определенный URI в метаданных (например, entityID или местоположение конечной точки) сопоставляется с ответственной стороной через компонент домена URI:

• Организация, владеющая доменом example.info отвечает за неопределенный объект SAML (например, поставщик удостоверений или поставщик услуг)
• Организация, владеющая доменом example.org отвечает за поставщика удостоверений SAML
• Организация, владеющая доменом example.com отвечает за поставщика услуг SAML
• Организация, владеющая доменом example.net является доверенной третьей стороной, ответственной за регистрацию и публикацию метаданных

Обратите внимание, что метаданные SAML описывают все стороны, участвующие в SSO веб-браузера SAML на основе метаданных, за исключением пользователя браузера. (См. профили SAML V2.0. спецификацию для получения дополнительной информации о системе единого входа веб-браузера SAML.)

Метаданные объекта

Следующий пример кода иллюстрирует общие технические характеристики SAML. <md:EntityDescriptor> элемент:

  <md:EntityDescriptor entityID="https://sso.example.info/entity" validUntil="2017-08-30T19:10:29Z"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi"
    xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- insert ds:Signature element (omitted) -->
    <md:Extensions>
      <mdrpi:RegistrationInfo registrationAuthority="https://registrar.example.net"/>
      <mdrpi:PublicationInfo creationInstant="2017-08-16T19:10:29Z" publisher="https://registrar.example.net"/>
      <mdattr:EntityAttributes>
        <saml:Attribute Name="http://registrar.example.net/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>
        </saml:Attribute>
      </mdattr:EntityAttributes>
    </md:Extensions>
    <!-- insert one or more concrete instances of the md:RoleDescriptor abstract type (see below) -->
    <md:Organization>
      <md:OrganizationName xml:lang="en">...</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">...</md:OrganizationDisplayName>
      <md:OrganizationURL xml:lang="en">https://www.example.info/</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 Атрибут — уникальный идентификатор сущности. Обратите внимание, что entityID — это неизменяемое имя объекта, а не местоположение.
• The validUntil Атрибут указывает дату истечения срока действия метаданных.
• The <ds:Signature> элемент (который для простоты опущен) содержит цифровую подпись, обеспечивающую подлинность и целостность метаданных. Предполагается, что подписавшим является доверенная третья сторона, называемая регистратором метаданных .
• The <mdrpi:RegistrationInfo> элемент расширения утверждает идентификатор регистратора метаданных.
• The <mdrpi:PublicationInfo> элемент расширения утверждает издатель метаданных (который совпадает с регистратором). creationInstant Атрибут указывает точный момент создания метаданных. Сравнивая стоимость creationInstant приписать значение validUntil атрибут, мы видим, что метаданные действительны в течение двух недель.
• The <mdattr:EntityAttributes> элемент расширения включает один атрибут сущности. Атрибут сущности утверждает, что сущность является «самосертифицированной» — предположительно желательное качество.
• Организация, указанная в <md:Organization> элемент «отвечает за объект», описанный дескриптором объекта (раздел 2.3.2 SAMLMeta ). <md:Organization> элемент содержит один или несколько дочерних элементов каждого типа с указанием языка.
• Контактная информация в <md:ContactPerson> Элемент идентифицирует техническое контактное лицо, ответственное за организацию. Возможны несколько контактов и типов контактов. См. раздел 2.3.2.2 SAMLMeta.

В этом первоначальном примере для краткости опущен важнейший дескриптор роли. Спецификация метаданных SAML определяет многочисленные конкретные экземпляры абстрактного типа md:RoleDescriptor (раздел 2.4.1 документа SAMLMeta). ). Две наиболее важные роли описаны <md:IDPSSODescriptor> элемент и <md:SPSSODescriptor> элемент. Каждый из этих ролевых дескрипторов проиллюстрирован в подразделах ниже.

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

Поставщик удостоверений SAML управляет конечной точкой службы единого входа. который получает запросы аутентификации от поставщиков услуг. Дескриптор сущности для поставщика удостоверений в этой роли содержит <md:IDPSSODescriptor> элемент, который сам содержит хотя бы один <md:SingleSignOnService> конечная точка. Следующий пример иллюстрирует две такие конечные точки:

  <md:EntityDescriptor entityID="https://sso.example.org/idp" validUntil="2017-08-30T19:10:29Z"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi"
    xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- insert ds:Signature element (omitted) -->
    <md:Extensions>
      <mdrpi:RegistrationInfo registrationAuthority="https://registrar.example.net"/>
      <mdrpi:PublicationInfo creationInstant="2017-08-16T19:10:29Z" publisher="https://registrar.example.net"/>
      <mdattr:EntityAttributes>
        <saml:Attribute Name="http://registrar.example.net/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>
        </saml:Attribute>
      </mdattr:EntityAttributes>
    </md:Extensions>
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <md:Extensions>
        <mdui:UIInfo>
          <mdui:DisplayName xml:lang="en">Example.org</mdui:DisplayName>
          <mdui:Description xml:lang="en">The identity provider at Example.org</mdui:Description>
          <mdui:Logo height="32" width="32" xml:lang="en">https://idp.example.org/myicon.png</mdui:Logo>
        </mdui:UIInfo>
      </md:Extensions>
      <md:KeyDescriptor use="signing">
        <ds:KeyInfo>...</ds:KeyInfo>
      </md:KeyDescriptor>
      <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:IDPSSODescriptor>
    <md:Organization>
      <md:OrganizationName xml:lang="en">Example.org Non-Profit Org</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Example.org</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>

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

• The <mdui:UIInfo> контейнер содержит набор элементов расширения с указанием языка, используемых для создания динамических пользовательских интерфейсов у поставщика услуг. Наиболее важным пользовательским интерфейсом поставщика услуг является интерфейс обнаружения поставщика удостоверений.
• Программное обеспечение поставщика удостоверений предположительно настроено с использованием частного ключа подписи SAML. Соответствующий открытый ключ включен в <md:KeyDescriptor use="signing"> элемент. В приведенном выше примере ключевой материал был опущен из ключевого дескриптора для краткости.
• The Binding атрибуты <md:SingleSignOnService> элементы представляют собой стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind ).

Ценности md:SingleSignOnService/@Location Атрибуты в метаданных поставщика удостоверений используются поставщиком услуг для маршрутизации сообщений SAML, что сводит к минимуму возможность того, что мошеннический поставщик удостоверений организует атаку «человек посередине» .

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

Поставщик услуг SAML управляет конечной точкой службы потребителей утверждений. который получает утверждения аутентификации от поставщиков удостоверений. Дескриптор сущности поставщика услуг в этой роли содержит <md:SPSSODescriptor> элемент, который сам содержит хотя бы один <md:AssertionConsumerService> конечная точка. Следующий пример иллюстрирует такую ​​конечную точку:

  <md:EntityDescriptor entityID="https://sso.example.com/portal" validUntil="2017-08-30T19:10:29Z"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:mdrpi="urn:oasis:names:tc:SAML:metadata:rpi"
    xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
    xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
    xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- insert ds:Signature element (omitted) -->
    <md:Extensions>
      <mdrpi:RegistrationInfo registrationAuthority="https://registrar.example.net"/>
      <mdrpi:PublicationInfo creationInstant="2017-08-16T19:10:29Z" publisher="https://registrar.example.net"/>
      <mdattr:EntityAttributes>
        <saml:Attribute Name="http://registrar.example.net/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
          <saml:AttributeValue>https://registrar.example.net/category/self-certified</saml:AttributeValue>
        </saml:Attribute>
      </mdattr:EntityAttributes>
    </md:Extensions>
    <md:SPSSODescriptor WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <md:Extensions>
        <mdui:UIInfo>
          <mdui:DisplayName xml:lang="en">Example.com Vendor Service</mdui:DisplayName>
          <mdui:InformationURL xml:lang="en">https://service.example.com/about.html</mdui:InformationURL>
          <mdui:PrivacyStatementURL xml:lang="en">https://service.example.com/privacy.html</mdui:PrivacyStatementURL>
          <mdui:Logo height="32" width="32" xml:lang="en">https://service.example.com/myicon.png</mdui:Logo>
        </mdui:UIInfo>
        <idpdisc:DiscoveryResponse index="0" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://service.example.com/SAML2/Login"/>
      </md:Extensions>
      <md:KeyDescriptor use="encryption">
        <ds:KeyInfo>...</ds:KeyInfo>
      </md:KeyDescriptor>
      <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
      <md:AssertionConsumerService index="0" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://service.example.com/SAML2/SSO/POST"/>
      <md:AttributeConsumingService index="0">
        <md:ServiceName xml:lang="en">Example.com Employee Portal</md:ServiceName>
        <md:RequestedAttribute isRequired="true"
          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13" FriendlyName="eduPersonUniqueId"/>
        <md:RequestedAttribute
          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail"/>
      </md:AttributeConsumingService>
    </md:SPSSODescriptor>
    <md:Organization>
      <md:OrganizationName xml:lang="en">Example.com Inc.</md:OrganizationName>
      <md:OrganizationDisplayName xml:lang="en">Example.com</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>

Содержание <md:SPSSODescriptor> Элемент описывает службу потребителя утверждений у поставщика услуг. Обратите внимание на следующие сведения об этом элементе:

• The WantAssertionsSigned атрибут на <md:SPSSODescriptor> элемент заявляет, что поставщик услуг хочет <saml:Assertion> элемент, подлежащий цифровой подписи. Этот атрибут заставляет поставщика удостоверений, поддерживающего метаданные, автоматически настраивать себя во время выполнения.
• The <mdui:UIInfo> элемент расширения содержит набор элементов расширения с указанием языка, используемых для создания динамических пользовательских интерфейсов у поставщика удостоверений. Двумя важными пользовательскими интерфейсами поставщика удостоверений являются страница входа и интерфейс согласия пользователя.
• The <idpdisc:DiscoveryResponse> элемент расширения определяет конечную точку, используемую при обнаружении поставщика удостоверений.
• Программное обеспечение поставщика услуг предположительно настроено с использованием частного ключа дешифрования SAML. Открытый ключ шифрования SAML включен в комплект поставки. <md:KeyDescriptor use="encryption"> элемент. В приведенном выше примере ключевой материал был опущен из ключевого дескриптора для краткости.
• The <md:NameIDFormat> элемент дает желаемый формат <saml:NameID> элемент в утверждении SAML. Присутствие этого элемента приводит к тому, что поставщик удостоверений, поддерживающий метаданные, автоматически настраивает себя во время выполнения.
• The index атрибут <md:AssertionConsumerService> элемент используется в качестве значения AssertionConsumerServiceIndex атрибут в <samlp:AuthnRequest> элемент.
• The Binding атрибут <md:AssertionConsumerService> Элемент — это стандартный URI, указанный в спецификации привязки SAML 2.0 (SAMLBind ).
• The <md:AttributeConsumingService> элемент используется поставщиком удостоверений для формирования <saml:AttributeStatement> элемент, который передается поставщику услуг вместе с единым входом в веб-браузер SAML.
• The index атрибут <md:AttributeConsumingService> элемент используется в качестве значения AttributeConsumingServiceIndex атрибут в <samlp:AuthnRequest> элемент.

Ценность md:AssertionConsumerService/@Location Атрибут в метаданных поставщика услуг используется поставщиком удостоверений для маршрутизации сообщений SAML, что сводит к минимуму возможность того, что мошеннический поставщик услуг организует атаку «человек посередине» .

Веб-браузер SAML на основе метаданных

Следующий поток протокола SAML предназначен для иллюстрации использования метаданных на различных этапах единого входа веб-браузера SAML. (См. профили SAML V2.0. спецификацию для получения дополнительной информации о системе единого входа веб-браузера SAML.)

Единый вход в веб-браузере SAML с обнаружением и входом в систему

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

Следующая последовательность иллюстрирует использование метаданных SAML для управления потоком протокола SAML.

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

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

 https://sp.example.com/myresource

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

2. Перенаправление на службу обнаружения.

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

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

302 Redirect
Location: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

Обратите внимание, что СП entityID включен в URL-адрес перенаправления, как указано в протоколе обнаружения.

3. Запросите услугу обнаружения.

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

GET /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal HTTP/1.1
Host: ds.example.com

Доверенные поставщики услуг в метаданных
Как служба обнаружения узнает, что поставщик услуг является подлинным, а не каким-то злобным самозванцем, пытающимся узнать поставщика удостоверений пользователя в гнусных целях?

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

(Узнайте предпочитаемый IdP пользователя)

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

Элементы пользовательского интерфейса в метаданных
Как служба обнаружения создает соответствующий интерфейс обнаружения?

Служба обнаружения обращается к своему доверенному хранилищу метаданных, чтобы определить соответствующий список доверенных поставщиков удостоверений, который будет представлен пользователю браузера. <mdui:UIInfo> Элементы пользовательского интерфейса в метаданных могут использоваться для создания интерфейса динамического обнаружения.

4. Перенаправление на конечную точку Discovery Response на SP.

Служба обнаружения теперь перенаправляет пользователя браузера на конечную точку ответа обнаружения у поставщика услуг:

302 Redirect
Location: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

Обратите внимание, что IdP entityID включен в URL-адрес перенаправления, как указано в протоколе обнаружения.

Расположение доверенных конечных точек в метаданных
Как служба обнаружения узнает, куда отправить пользователя с IdP? entityID?

Служба обнаружения ищет заранее заданное местоположение конечной точки Discovery Response доверенного поставщика услуг в метаданных .

5. Запросите конечную точку Discovery Response у SP.

Пользователь браузера запрашивает конечную точку Discovery Response у поставщика услуг посредством перенаправления:

GET /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp HTTP/1.1
Host: sp.example.com

Конечная точка ответа обнаружения у поставщика услуг соответствует протоколу и профилю службы обнаружения поставщика удостоверений.

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

Как поставщик услуг узнает, что поставщик удостоверений, предоставленный entityID URL-адрес протокола обнаружения является подлинным, а не каким-то злобным поставщиком удостоверений, пытающимся подделать пароль пользователя?

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

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

Поставщик услуг генерирует соответствующий <samlp:AuthnRequest> элемент, кодирует запрос SAML в строке запроса URL-адреса, а затем перенаправляет пользователя браузера в службу единого входа у провайдера удостоверений:

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

Подробное описание построения строки запроса см. в соответствующем потоке протокола SAML в статье SAML 2.0. Обратитесь к SAMLCore для получения подробной информации.

Расположение доверенных конечных точек в метаданных
Как поставщик услуг узнает, куда направить пользователя с запросом SAML?

Поставщик услуг ищет заранее заданное местоположение конечной точки доверенного поставщика удостоверений в метаданных .

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

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

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

Доверенные поставщики услуг в метаданных
Как поставщик удостоверений узнает, что поставщик услуг является подлинным, а не каким-то злобным поставщиком услуг, пытающимся собрать личную информацию о пользователе?

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

8. Ответьте на странице входа.

Поставщик удостоверений возвращает страницу входа в браузер пользователя. Страница входа содержит HTML-форму, подобную следующей:

  <form method="post" action="https://idp.example.com/login-response" ...>
    Username:<br>
    <input type="text" name="username"><br>
    Password:<br>
    <input type="password" name="password">
    ...
    <input type="submit" value="Submit" />
  </form>

Элементы пользовательского интерфейса в метаданных
Чтобы успокоить пользователя браузера, IdP персонализирует страницу входа с помощью <mdui:UIInfo> элементы пользовательского интерфейса в метаданных.

9. Отправьте форму входа.

Пользователь браузера отправляет HTML-форму провайдеру удостоверений:

POST /login-response HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
 
username=username&password=password

(Выдать пользователю подтверждение SAML)

На этом этапе поставщик удостоверений знает личность субъекта-пользователя и поэтому создает утверждение SAML от имени субъекта-пользователя. Конкретный пример такого утверждения см. в соответствующем потоке протокола SAML в статье SAML 2.0. Как всегда, обратитесь к SAMLCore. для получения подробной информации.

The <saml:NameID> Элемент в утверждении SAML кодирует идентификатор субъекта-пользователя. В этом случае поставщик удостоверений включает временный идентификатор имени SAML2 (SAMLCore). ) в утверждении SAML.

Формат NameID в метаданных
Почему поставщик удостоверений использует в утверждении SAML формат Transient NameID (а не какой-либо другой формат)?

Предполагая <samlp:AuthnRequest> элемент, выданный поставщиком услуг, не запрашивает иное, IdP, знающий метаданные, обратится к <md:NameIDFormat> элементы в метаданных (если есть) для определения формата NameID.

Поставщик удостоверений включает в утверждение SAML два атрибута пользователя: eduPersonUniqueId и mail.

Запрошенные атрибуты в метаданных
Почему поставщик удостоверений включает атрибуты eduPersonUniqueId и mail в утверждении, а не в каких-то других атрибутах?

Знающий метаданные IdP проконсультируется с <md:RequestedAttribute> элементы в метаданных (если таковые имеются), чтобы узнать требования поставщика услуг к атрибутам.

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

Атрибут WantAssertionsSigned в метаданных
Как поставщик удостоверений узнает, что поставщик услуг хочет, чтобы само утверждение было подписано цифровой подписью?

Во время выполнения поставщик удостоверений замечает, что WantAssertionsSigned Атрибут XML в метаданных имеет значение true.

Доверенный сертификат шифрования в метаданных
Как поставщик удостоверений шифрует утверждение SAML, чтобы поставщик услуг (и только поставщик услуг) мог его расшифровать?

Во время выполнения поставщик удостоверений использует сертификат шифрования поставщика услуг в метаданных для шифрования утверждения.

10. Ответьте на странице ответа SAML.

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

Расположение доверенных конечных точек в метаданных
Как поставщик удостоверений узнает, куда отправить пользователя с ответом SAML?

Поставщик удостоверений ищет заранее заданное местоположение конечной точки доверенного поставщика услуг в метаданных .

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

Форма XHTML автоматически отправляется браузером (из-за небольшого количества JavaScript на странице):

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

Сертификат доверенной подписи в метаданных
Как поставщик услуг узнает, что ответ SAML пришел от доверенного поставщика удостоверений?

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

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

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

302 Redirect
Location: https://sp.example.com/myresource

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

Наконец, пользователь браузера запрашивает целевой ресурс у поставщика услуг посредством перенаправления:

 https://sp.example.com/myresource

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

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

См. также

• Язык разметки утверждений безопасности (SAML)
• SAML 2.0
• XML (расширяемый язык разметки)
• XML-схема (W3C)
• XML-подпись
• XML-шифрование

Ссылки

Спецификации метаданных Liberty

Примечание. Схема метаданных Liberty дословно указана в документах со спецификациями, перечисленных ниже. Поскольку прямая ссылка на документ XSD версии 1.1 на веб-сайте Liberty не работает, копия документа XSD для метаданных Liberty версии 1.1 была загружена в Интернет. Этот документ также включен в устаревший архив Liberty ID-FF 1.2 .

Стандарты SAML

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

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

За исключением исторических ссылок на исходный стандарт метаданных SAML V2.0, следующие сноски указывают на спецификации SAML V2.0 с опечатками . Последние спецификации полностью включают все ошибки, одобренные Техническим комитетом OASIS Security Services (SAML) с момента публикации стандартов SAML V2.0 в марте 2005 года. можно найти на Wiki OASIS SAML Самые последние версии любой спецификации SAML .

Спецификации комитета после 2005 г.

Это небольшая часть спецификаций комитета «Post-V2.0», опубликованная Техническим комитетом OASIS Security Services (SAML). Пожалуйста, обратитесь к OASIS SAML Wiki для получения самой последней версии любой спецификации SAML.