Сэмл-протокол

Традиционно корпоративные приложения развертываются и запускаются в корпоративных сетях. Чтобы получить информацию о пользователях, такую ​​как профили пользователей и информацию о группах, многие из этих приложений созданы для интеграции с корпоративными каталогами, такими как Microsoft Active Directory. Более того, каталог часто используется для хранения и аутентификации учетных данных пользователя. Например, если вы используете SharePoint и Exchange, работающие локально, ваши учетные данные для входа — это ваши учетные данные Active Directory.

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

Хотите узнать больше о Сэмл-протокол,Вы можете обратиться к соответствующемуОфициальная документация。

Службы аутентификации

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

федеративная идентичность

Федеративная идентичность начинается с необходимости поддерживать доступ к приложениям за пределами компании или организации.

Представьте себе отношения между компанией по производству соков (JuiceCo), продающей свою продукцию крупной сети супермаркетов (BigMart).

Как сотруднику JuiceCo, вам понадобится доступ к приложениям BigMart для управления взаимоотношениями и мониторинга поставок и продаж.

В этом случае BigMart (который предоставляет приложение) должен будет отвечать за аутентификацию пользователей.

Самый простой способ — попросить пользователей, работающих в JuiceCo, использовать разные имена пользователей и пароли.

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

Лучшим способом решения этой проблемы было бы позволить JuiceCo и всем другим поставщикам использовать или объединить личность BigMart.

Как сотрудник JuiceCo, у вас уже есть фирменный стиль и учетные данные.

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

Этот вариант использования привел к созданию объединенных протоколов, таких как язык разметки утверждений безопасности (SAML) (откроется в новом окне).

SAML-планирование

SAML в основном используется как механизм веб-аутентификации, поскольку он основан на использовании прокси-сервера браузера для прокси-сервера потока аутентификации. На высоком уровне процесс аутентификации для SAML выглядит следующим образом:

Вставьте сюда описание изображения

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

SP

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

IdP

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

SAML-запрос

SAML-запрос,Также известен как запрос аутентификации,Создается поставщиком услуг для «запроса» аутентификации.

SAML-ответ

SAML-ответ генерируется провайдером удостоверений. Он содержит фактическое утверждение аутентифицированного пользователя. также,SAML-ответ может содержать дополнительную информацию,Например,Информация профиля пользователя и информация о группе/роли,Это зависит от того, что может поддерживать поставщик услуг.

Запуск поставщика услуг (запуск SP)

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

Запуск поставщика удостоверений (запуск IdP)

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

Несколько ключевых моментов, на которые следует обратить внимание

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

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

контрольный список планирования

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

• Понять роль поставщиков услуг。
• Единая схема идентификации и множественные схемы идентификации。
• Понимание процесса входа в систему, инициированного SP。
• Раскройте конфигурацию SAML в SP。
• Включите SAML для всех, а не только для некоторых пользователей。
• Реализация «черного хода»

Понять роль поставщиков услуг

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

Для выполнения этой операции SP требуется как минимум следующее:

• Сертификат. SP необходимо получить общедоступный сертификат от IdP для проверки подписи. Сертификат хранится на стороне SP.,И использовать его, когда придет SAML-ответ.
• Конечная точка ACS — URL-адрес службы подтверждения потребителя — для краткости часто называемый URL-адресом для входа в SP. Это конечная точка, предоставляемая поставщиком услуг, публикующим SAML-ответ. Поставщик услуг должен предоставить эту информацию IdP.
• URL-адрес входа в IdP — это конечная точка стороны IdP, выдающей SAML-запрос.,Поставщик услуг должен получить эту информацию от IdP.

Самый простой способ реализовать SAML — использовать набор инструментов SAML с открытым исходным кодом. Эти наборы инструментов обеспечивают логику, необходимую для обработки информации, передаваемой в SAML-ответ. также,Если поставщику услуг требуется поддержка процесса входа в систему, инициированного поставщиком услуг,Инструментарий также предоставляет логику, необходимую для генерации соответствующих запросов аутентификации SAML.

Единая схема идентификации и множественные схемы идентификации

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

Вставьте сюда описание изображения

Если вы являетесь независимым поставщиком программного обеспечения (ISV), создающим корпоративный продукт SaaS, или создаете внешний веб-сайт/портал/сообщество для своих клиентов и партнеров, вам необходимо рассмотреть возможность поддержки нескольких IdP. Это типичный вариант использования для многих независимых поставщиков программного обеспечения SaaS, которым необходимо интегрироваться с корпоративной инфраструктурой идентификации своих клиентов. В зависимости от архитектуры вашего приложения вам необходимо подумать о том, как хранить конфигурацию SAML от каждого поставщика удостоверений (например, сертификат или URL-адрес входа в систему IdP) и как предоставлять необходимую информацию SP каждому поставщику.

Вставьте сюда описание изображения

Одним из ключевых замечаний является публикация ACS на стороне SP SAML-ответа. Конечная точка URL-адреса. Даже при работе с несколькими IdP,Также возможно предоставить отдельные конечные точки. Для одноэкземплярных мультитенантных приложений без определения аренды в URL-адресе (при использовании поддоменов),Это может быть более простой способ реализовать это. но,ты должен положиться наSAML-ответдополнительная информация вIdPПопытка аутентификации(Например,используя IssuerID). Если ваше приложение настроено в многопользовательском режиме,И включите информацию о домене в URL-адрес (Например,использоватьhttps://domain1.example.comилиhttps://www.example.com/domain1),),тогда было бы неплохо иметь конечную точку ACSURL для каждого поддомена.,Потому что сам URL-адрес может идентифицировать домен.

Вставьте сюда описание изображения

Понимание процесса входа в систему, инициированного SP

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

В потоке, инициированном SP,Пользователь пытается получить доступ к защищенным ресурсам непосредственно на стороне SP.,И IdP не знает, что попробовать. Возникают две проблемы. первый,Если вам необходимо подтвердить федеративную идентичность,Вам необходимо определить правильный IdP. При использовании входа в систему, инициированного SP,ИП изначально ничего не знал о личности. как разработчик,Вам нужно разобраться, как ИП определяет, какой IdP должен получить SAML-запрос. в некоторых случаях,Если URL-адрес вашего приложения содержит информацию о субдомене, сопоставленную с уникальным клиентом и IdP,Тогда ссылки на ресурс обращения будет достаточно для идентификации IdP. если бы это было не так,конечному пользователю может потребоваться запрос на предоставление дополнительной информации от конечного пользователя,Например, идентификатор пользователя, адрес электронной почты или идентификатор компании. Вам нужно что-то, что позволит поставщику услуг определить, к какому IdP принадлежит пользователь, пытающийся получить доступ к ресурсу. пожалуйста, запомни,Вам просто будет предложено ввести идентификатор,вместо удостоверений. Okta также поддерживает передачу удостоверения личности IdP через параметр LoginHint.,Таким образом, когда пользователь перенаправляется к IdP для входа в систему,Повторно вводить идентификатор не требуется. Инструкции по запуску OKTA для отправки «LoginHint» IdP,См. раздел «Использование перенаправлений глубоких ссылок SAML».

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

SAML — это специально разработанный асинхронный протокол.。SPИнициированный процесс входа в систему генерируется изSAMLЗапрос аутентификации начинается,Запрос перенаправляется IdP. в это время,SP не хранит никакой информации о запросе. Когда SAML-ответ возвращается от IdP,Поставщик услуг ничего не будет знать об исходной глубокой ссылке, которая инициировала запрос аутентификации. к счастью,SAML поддерживает это через параметр RelayState.

RelayState

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

В случае глубокой ссылки,SP устанавливает RelayState SAML-запроса, используя значение глубокой ссылки. Когда возвращается SAML-ответ,Поставщик услуг может использовать значение RelayState и направить аутентифицированного пользователя на правильный ресурс.

Вставьте сюда описание изображения

Раскройте конфигурацию SAML в SP

Как упоминалось ранее, SP требует настройки IdP для завершения настройки SAML. Хотя многие независимые поставщики программного обеспечения предпочитают делать это через поддержку и электронную почту, лучший подход — предоставить ИТ-администратору клиента страницу администрирования самообслуживания для включения SAML. SAML поддерживает метаданные на стороне IdP и SP. Один из способов настройки отношений IdP/SP на стороне SP — установить возможность получения файлов метаданных IdP и возможность генерировать файлы метаданных SP для использования IdP. Это предпочтительный метод.

Однако,Некоторые независимые поставщики ПО предпочитают разрешать прямую настройку нескольких ключевых параметров SAML.,а не через файлы метаданных. Типичные параметры включают URL-адрес перенаправления IdP (для SAML-запроса), IssuerID, URL-адрес выхода из IdP. Поставщик услуг также должен разрешить загрузку или сохранение общедоступных сертификатов IdP.

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

Включите SAML для всех, а не только для некоторых пользователей

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

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

Реализация «черного хода»

Это особенно важно, если все участники вашего приложения планируют включить SAML. Иногда в конфигурации SAML может возникнуть ошибка или что-то изменилось в конечной точке SAML IdP. Несмотря ни на что, вы не хотите, чтобы вас полностью заблокировали. Предоставление администраторам возможности использовать бэкдоры для доступа к заблокированным системам становится чрезвычайно важным. Обычно это достигается за счет наличия «секретного» URL-адреса входа, доступ к которому не вызывает перенаправления SAML. Обычно администратор входит в систему, используя имя пользователя и пароль, и вносит необходимые изменения для решения проблемы.

Справочные ресурсы

• Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
• Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0
• Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0