Метаданные SAML - SAML metadata - Wikipedia

^{[CS 1]}В Метаданные SAML Стандарт принадлежит к семейству стандартов на основе XML, известных как Язык разметки утверждения безопасности (SAML) опубликовано ОАЗИС в 2005 году. Документ метаданных SAML описывает развертывание SAML, например Поставщик удостоверений SAML или Поставщик услуг SAML. Развертывания обмениваются метаданными, чтобы установить базовый уровень доверия и взаимодействия.

Введение в метаданные SAML

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

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

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

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

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

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

Чтобы полностью автоматизировать процесс обмена метаданными, необходим стандартный формат файла. С этой целью спецификация метаданных SAML V2.0^{[OS 1]} определяет стандартное представление для метаданных SAML, которое упрощает настройку программного обеспечения SAML и позволяет создавать безопасные автоматизированные процессы для обмена метаданными.

Взаимодействие на основе метаданных

По мере развития технологии SAML важность метаданных SAML постоянно возрастает. Сегодня реализация, поддерживающая веб-браузер SAML Единая точка входа требуется файл метаданных SAML с допустимой схемой для каждого партнера SAML. (См. Профили SAML V2.0^{[OS 2]} спецификацию для получения дополнительной информации о системе единого входа в веб-браузере 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. Это несоответствие приводит к проблемам совместимости.

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

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

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

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

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

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

История метаданных SAML

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

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

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

«whois для федераций SAML» (на основе Организация и Контактное лицо элементы в метаданных)
динамическое обнаружение метаданных (с разрешением через DNS и известное местоположение)
безопасность на уровне документа с использованием подписи XML

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

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

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

Соответствующий Рекомендации в рабочий поток Liberty приведены в конце статьи. Исходная схема метаданных, внесенная в OASIS, полностью указана в разделе 7 Liberty Metadata Version 1.0.^{[LibertyMeta 1]} Технические характеристики. Точно так же спецификация для Liberty Metadata Version 1.1^{[LibertyMeta 2]} включает листинг схемы версии 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.^{[SAMLMeta 1]} С этого момента рабочие потоки Liberty и OASIS развивались одновременно (но не независимо, поскольку над обеими спецификациями работали одни и те же люди). В период с марта по июль 2004 г. только что сформировавшаяся спецификация метаданных SAML претерпела значительный отток.

В июле 2004 года SSTC выпустил публичный звонок для комментариев охватывающий полный набор черновых спецификаций SAML V2.0. В этот набор спецификаций был включен рабочий проект недавно созданной спецификации метаданных SAML V2.0.^{[SAMLMeta 2]}

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

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

Набор спецификаций V2.0 (см. Рекомендации раздел для полного списка) включал окончательную спецификацию метаданных SAML V2.0.^{[OS 1]} Десять лет спустя, в сентябре 2015 года, OASIS опубликовал пересмотренную спецификацию метаданных SAML с исправлениями.^{[OS 3]} В результате исходная спецификация метаданных устарела, как и другие документы в исходном наборе спецификаций 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. Поскольку веб-профили SSO Liberty Alliance напрямую основаны на профилях SAML Web SSO, метаданные, определенные в этом документе, во многом заимствованы из определений метаданных в проекте спецификаций Liberty Alliance 1.2. (Из "Метаданных для профилей SSO веб-браузера SAML 2.0"^{[SAMLMeta 4]})

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

По следам документа влияние Liberty ID-FF на метаданные SAML можно проследить до проекта спецификации, опубликованного в апреле 2003 года.^{[SAMLMeta 6]} Это первый известный документ OASIS, который ссылается на Liberty ID-FF, в частности, на Liberty Metadata Version 1.0-06,^{[LibertyMeta 3]} ранняя версия спецификации метаданных Liberty, о которой мало что известно. Однако ясно, что «Метаданные для профилей веб-браузера SAML 1.1» были задуманы как дополнение к стандарту SAML V1.1, но, конечно, мы знаем, что V1.1 не определяет использование метаданных. Соответствующие предположения см. В следующем разделе.

Могут быть интересны две ранние схемы метаданных:

В июне 2002 года, всего через месяц после того, как SSTC завершила свою работу над тем, что должно было стать стандартом SAML V1.0, Шибболет проект разработан схема метаданных состоящий из <OriginSite> и <DestinationSite> элементы. Эта схема будет управлять начальными версиями программного обеспечения Shibboleth IdP.

В феврале 2003 года SSTC выпустила черновик схемы спецификации метаданных под названием «Метаданные для профилей веб-браузера SAML 1.0».^{[SAMLMeta 7]} Однако эта схема остается любопытной, поскольку уже в следующей версии этого потока документов (и во всех последующих версиях) будет использоваться синтаксис метаданных Liberty.

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

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

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

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

Спецификации Post-V2.0

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

Расширения метаданных SAML V2.0 для информации о регистрации и публикации Версия 1.0.^{[CS 1]}
Расширение метаданных SAML V2.0 для атрибутов объекта.^{[CS 2]}
SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0.^{[CS 3]}
Протокол и профиль службы обнаружения поставщика удостоверений.^{[CS 4]}
Протокол инициирования запроса поставщика услуг и версия профиля 1.0.^{[CS 5]}
Профиль метаданных SAML V2.0 для поддержки алгоритмов версии 1.0.^{[CS 6]}

Важной спецификацией "Post-V2.0" является Профиль взаимодействия метаданных SAML V2.0,^{[CS 7]} который основан на предпосылке, что формальная инфраструктура открытого ключа (PKI) может быть чрезвычайно сложной и в некоторых случаях трудноразрешимой (например, хорошо известно, что отзыв сертификата TLS в браузере нарушен^{[Разное 1]}). По сути, Профиль взаимодействия метаданных это попытка предоставить работающий механизм отзыва ключей для федераций SAML.

С момента публикации в августе 2009 г. Профиль взаимодействия метаданных был особенно влиятельным документом, особенно в сфере высшего образования (см., например, требования к сертификатам для разработчиков^{[Разное 2]} в одной крупной федерации R&E). Совместимость метаданных играет ключевую роль в формальном профиле реализации, опубликованном Kantara Initiative:

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

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

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

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

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

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

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

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

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

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

   entityID ="https://sso.example.info/entity" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="урна: оазис: имена: tc: SAML: 2.0: метаданные"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    xmlns: mdrpi ="urn: oasis: names: tc: SAML: metadata: rpi"    xmlns: mdattr ="урна: оазис: имена: tc: SAML: метаданные: атрибут"    xmlns: ds ="http://www.w3.org/2000/09/xmldsig#">    <!-- insert ds:Signature element (omitted) -->    <md:Extensions>       registrationAuthority ="https://registrar.example.net"/>       creationInstant ="2017-08-16T19: 10: 29Z" издатель ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Имя ="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>       xml: lang ="en">...</md:OrganizationName>       xml: lang ="en">...</md:OrganizationDisplayName>       xml: lang ="en">https://www.example.info/</md:OrganizationURL>    </md:Organization>     contactType ="технический">      <md:SurName>Техническая поддержка SAML</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

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

В entityID Атрибут - уникальный идентификатор объекта. Обратите внимание, что entityID - неизменное имя объекта, а не местоположение.
В действительна до Атрибут указывает дату истечения срока действия метаданных.
В <ds:Signature> Элемент (который был опущен для простоты) содержит цифровую подпись, которая обеспечивает подлинность и целостность метаданных. Предполагается, что подписавшая сторона является доверенной третьей стороной, называемой регистратор метаданных.
В <mdrpi:RegistrationInfo> элемент расширения^{[CS 1]} утверждает идентификатор регистратора метаданных.
В <mdrpi:PublicationInfo> элемент расширения^{[CS 1]} утверждает издателя метаданных (который совпадает с регистратором). В создание Мгновенное Атрибут указывает точное время создания метаданных. Сравнение стоимости создание Мгновенное атрибут к значению действительна до атрибут, видим, что метаданные действительны две недели.
В <mdattr:EntityAttributes> элемент расширения^{[CS 2]} включает один атрибут сущности. Атрибут объекта утверждает, что объект является «самосертифицированным», что предположительно является желательным качеством.
Организация, указанная в <md:Organization> элемент «отвечает за объект», описанный дескриптором объекта (раздел 2.3.2 SAMLMeta^{[OS 3]}). В <md:Organization> element содержит один или несколько дочерних элементов каждого типа с указанием языка.
Контактная информация в <md:ContactPerson> Элемент идентифицирует контактное лицо по техническим вопросам, ответственное за организацию. Возможны несколько контактов и типов контактов. См. Раздел 2.3.2.2 SAMLMeta.^{[OS 3]}

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

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

А Поставщик удостоверений SAML управляет конечной точкой службы единого входа^{[OS 2]} который получает запросы аутентификации от поставщиков услуг. Дескриптор объекта для поставщика удостоверений в этой роли содержит <md:IDPSSODescriptor> элемент, который сам содержит хотя бы один <md:SingleSignOnService> конечная точка. В следующем примере показаны две такие конечные точки:

   entityID ="https://sso.example.org/idp" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="урна: оазис: имена: tc: SAML: 2.0: метаданные"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    xmlns: mdrpi ="urn: oasis: names: tc: SAML: metadata: rpi"    xmlns: mdattr ="урна: оазис: имена: tc: SAML: метаданные: атрибут"    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>       registrationAuthority ="https://registrar.example.net"/>       creationInstant ="2017-08-16T19: 10: 29Z" издатель ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Имя ="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>     protocolSupportEnumeration ="урна: оазис: имена: tc: SAML: 2.0: протокол">      <md:Extensions>        <mdui:UIInfo>           xml: lang ="en">Example.org</mdui:DisplayName>           xml: lang ="en">Поставщик удостоверений на Example.org</mdui:Description>           высота ="32" ширина ="32" xml: lang ="en">https://idp.example.org/myicon.png</mdui:Logo>        </mdui:UIInfo>      </md:Extensions>       использовать ="подписание">        <ds:KeyInfo>...</ds:KeyInfo>      </md:KeyDescriptor>       Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect" Расположение ="https://idp.example.org/SAML2/SSO/Redirect"/>       Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST" Расположение ="https://idp.example.org/SAML2/SSO/POST"/>    </md:IDPSSODescriptor>    <md:Organization>       xml: lang ="en">Example.org Некоммерческая организация</md:OrganizationName>       xml: lang ="en">Example.org</md:OrganizationDisplayName>       xml: lang ="en">https://www.example.org/</md:OrganizationURL>    </md:Organization>     contactType ="технический">      <md:SurName>Техническая поддержка SAML</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

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

В <mdui:UIInfo> контейнер^{[CS 3]} содержит набор элементов расширения с указанием языка, используемых для создания динамических пользовательских интерфейсов у поставщика услуг. Самый важный пользовательский интерфейс поставщика услуг - это интерфейс обнаружения поставщика удостоверений.
Программное обеспечение поставщика удостоверений предположительно настроено с использованием частного ключа подписи SAML. Соответствующий открытый ключ включен в <md:KeyDescriptor use="signing"> элемент. В приведенном выше примере ключевой материал был опущен из ключевого дескриптора для краткости.
В Привязка атрибуты <md:SingleSignOnService> элементы - это стандартные URI, указанные в спецификации привязки SAML 2.0 (SAMLBind^{[OS 5]}).

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

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

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

   entityID ="https://sso.example.com/portal" validUntil ="2017-08-30T19: 10: 29Z"    xmlns: md ="урна: оазис: имена: tc: SAML: 2.0: метаданные"    xmlns: saml ="urn: oasis: names: tc: SAML: 2.0: assertion"    xmlns: mdrpi ="urn: oasis: names: tc: SAML: metadata: rpi"    xmlns: mdattr ="урна: оазис: имена: tc: SAML: метаданные: атрибут"    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>       registrationAuthority ="https://registrar.example.net"/>       creationInstant ="2017-08-16T19: 10: 29Z" издатель ="https://registrar.example.net"/>      <mdattr:EntityAttributes>         Имя ="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>     WantAssertionsSigned ="истинный" protocolSupportEnumeration ="урна: оазис: имена: tc: SAML: 2.0: протокол">      <md:Extensions>        <mdui:UIInfo>           xml: lang ="en">Служба поставщика Example.com</mdui:DisplayName>           xml: lang ="en">https://service.example.com/about.html</mdui:InformationURL>           xml: lang ="en">https://service.example.com/privacy.html</mdui:PrivacyStatementURL>           высота ="32" ширина ="32" xml: lang ="en">https://service.example.com/myicon.png</mdui:Logo>        </mdui:UIInfo>         index ="0" Привязка ="urn: oasis: names: tc: SAML: profiles: SSO: idp-discovery-protocol" Расположение ="https://service.example.com/SAML2/Login"/>      </md:Extensions>       использовать ="шифрование">        <ds:KeyInfo>...</ds:KeyInfo>      </md:KeyDescriptor>      <md:NameIDFormat>urn: oasis: names: tc: SAML: 2.0: nameid-format: временный</md:NameIDFormat>       index ="0" Привязка ="urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST"  Расположение ="https://service.example.com/SAML2/SSO/POST"/>       index ="0">         xml: lang ="en">Портал сотрудников Example.com</md:ServiceName>         isRequired ="истинный"          NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"          Имя ="urn: oid: 1.3.6.1.4.1.5923.1.1.1.13" FriendlyName ="eduPersonUniqueId"/>                  NameFormat ="urn: oasis: names: tc: SAML: 2.0: attrname-format: uri"          Имя ="урна: oid: 0.9.2342.19200300.100.1.3" FriendlyName ="Почта"/>      </md:AttributeConsumingService>    </md:SPSSODescriptor>    <md:Organization>       xml: lang ="en">Example.com Inc.</md:OrganizationName>       xml: lang ="en">Example.com</md:OrganizationDisplayName>       xml: lang ="en">https://www.example.com/</md:OrganizationURL>    </md:Organization>     contactType ="технический">      <md:SurName>Техническая поддержка SAML</md:SurName>      <md:EmailAddress>mailto: [email protected]</md:EmailAddress>    </md:ContactPerson>  </md:EntityDescriptor>

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

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

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

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

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

Система единого входа в веб-браузере SAML с обнаружением и входом

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

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

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

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

 https://sp.example.com/myresource

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

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

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

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

302 перенаправлениеРасположение: https://ds.example.com/idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal

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

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

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

ПОЛУЧАТЬ /idpdisc?entityID=https%3A%2F%2Fsso.example.org%2Fportal HTTP/1.1Хозяин: ds.example.com

Надежные поставщики услуг в метаданных

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

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

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

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

Элементы пользовательского интерфейса в метаданных

Как служба обнаружения создает соответствующий интерфейс обнаружения?

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

4. Перенаправление на конечную точку отклика обнаружения на SP

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

302 перенаправлениеРасположение: https://sp.example.com/SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp

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

Расположение надежных конечных точек в метаданных

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

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

5. Запросить конечную точку отклика обнаружения на SP

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

ПОЛУЧАТЬ /SAML2/Login?entityID=https%3A%2F%2Fsso.example.org%2Fidp HTTP/1.1Хозяин: sp.example.com

Конечная точка Discovery Response у поставщика услуг соответствует Протокол и профиль службы обнаружения поставщика удостоверений.^{[CS 4]}

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

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

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

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

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

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

Схему построения строки запроса см. В соответствующих Поток протокола SAML в статье SAML 2.0. Обратитесь к SAMLCore^{[OS 6]} для подробностей.

Расположение надежных конечных точек в метаданных

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

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

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

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

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

Надежные поставщики услуг в метаданных

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

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

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

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

  <форма метод="почтовый" действие="https://sp.example.com/login-response" ...>    Имя пользователя:<br>    <Вход тип="текст" имя="имя пользователя"><br>    Пароль:<br>    <Вход тип="пароль" имя="пароль">    ...    <Вход тип="Разместить" ценить="Представлять на рассмотрение" />  </форма>

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

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

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

ПОЧТОВЫЙ / логин-ответ HTTP/1.1Хозяин: sp.example.comТип содержимого: приложение / x-www-form-urlencodedContent-Length: nnnимя пользователя = имя пользователя и пароль = пароль

(Выпустите SAML Assertion для пользователя)

На этом этапе поставщик удостоверений знает удостоверение участника-пользователя, и поэтому поставщик удостоверений создает утверждение SAML от имени участника-пользователя. Конкретный пример такого утверждения см. В соответствующих Поток протокола SAML в статье SAML 2.0. Как всегда, обратитесь к SAMLCore^{[OS 6]} для подробностей.

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

Формат NameID в метаданных

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

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

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

Запрошенные атрибуты в метаданных

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

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

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

Атрибут WantAssertionsSigned в метаданных

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

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

Надежный сертификат шифрования в метаданных

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

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

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

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

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

Расположение надежных конечных точек в метаданных

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

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

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

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

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

Надежный сертификат подписи в метаданных

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

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

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

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

302 перенаправлениеРасположение: https://sp.example.com/myresource

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

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

 https://sp.example.com/myresource

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

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

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

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

Метаданные SAML - SAML metadata - Wikipedia

Содержание

Введение в метаданные SAML

Взаимодействие на основе метаданных

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

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

История метаданных SAML

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

После ноября 2003 г.

До ноября 2003 г.

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

Спецификации Post-V2.0

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

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

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

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

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

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

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

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

4. Перенаправление на конечную точку отклика обнаружения на SP

5. Запросить конечную точку отклика обнаружения на SP

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

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

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

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

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

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

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

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

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

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

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

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

Спецификации метаданных SAML до 2005 г.

Стандарты SAML

Технические характеристики комитета после 2005 г.

Разное