Эта статья первоначально опубликована на https://www.learncsdesign.com.

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

Крупный корпоративный клиент может ожидать, что ваше приложение будет поддерживать аутентификацию SAML 2.0.

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

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

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

Терминология SAML

SAML определяет следующие термины:

  • Subject — объект, о котором будет осуществляться обмен информацией о безопасности.
  • Утверждение SAML. Информация о безопасности субъекта содержится в сообщениях на основе XML.
  • Профиль SAML — Спецификация для использования сообщений SAML в бизнес-приложениях, таких как междоменный единый вход.
  • Поставщик удостоверений. Поставщик удостоверений — это сервер, который выдает утверждения SAML об аутентифицированном субъекте в контексте междоменного единого входа.
  • Поставщик услуг. Поставщик услуг делегирует аутентификацию поставщику удостоверений и полагается на информацию об аутентифицированном субъекте в утверждении SAML, выдаваемом поставщиком удостоверений в контексте междоменного единого входа.
  • Доверительные отношения — соглашение между поставщиком услуг SAML и поставщиком удостоверений SAML, согласно которому поставщик услуг доверяет утверждениям, выданным поставщиком удостоверений.
  • Привязка протокола SAML — описание того, как элементы сообщения SAML сопоставляются со стандартными протоколами связи, такими как HTTP, для передачи между поставщиками услуг и поставщиками удостоверений.

Как работает SAML

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

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

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

Приложение (поставщик услуг) инициировало единый вход

  1. Пользователь посещает поставщика услуг (приложение).
  2. Браузер пользователя перенаправляется к поставщику удостоверений с запросом аутентификации SAML.
  3. Во время аутентификации поставщик удостоверений взаимодействует с пользователем.
  4. Пользователь аутентифицируется, а поставщик удостоверений проверяет учетные данные.
  5. С ответом SAML поставщик удостоверений перенаправляет браузер пользователя обратно к поставщику услуг. Ответ отправляется на URL-адрес службы приема утверждений (ACS) поставщика услуг.
  6. Как только поставщик услуг получает ответ SAML, он обрабатывает и проверяет его и отвечает на первоначальный запрос пользователя.

Единая точка входа

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

Поток, инициированный поставщиком удостоверений

В предыдущем разделе показана последовательность взаимодействия с пользователем, начиная с поставщика услуг. Он называется SP-Initiated, потому что пользователь инициирует взаимодействие.

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

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

  1. Пользователь заходит на корпоративный портал.
  2. Браузер пользователя перенаправляется к поставщику удостоверений с запросом аутентификации SAML.
  3. Чтобы аутентифицировать пользователя, поставщик удостоверений взаимодействует с пользователем.
  4. Учетные данные проверяются поставщиком удостоверений после аутентификации пользователя.
  5. Ответ SAML для портала, содержащий подтверждение аутентификации, возвращается поставщиком удостоверений в браузер пользователя. Список приложений отображается пользователю после входа на портал.
  6. Пользователь на портале щелкает ссылку приложения. Браузер пользователя направляется к поставщику удостоверений с параметром, указывающим желаемое приложение поставщика услуг. IdP проверяют сеанс пользователя.
  7. Браузер пользователя перенаправляется на URL-адрес службы утверждения (ACS) поставщика услуг с новым ответом SAML.
  8. Предполагая, что идентификатора и привилегий пользователя достаточно, поставщик услуг отображает соответствующую страницу для пользователя на основе ответа SAML и утверждения аутентификации.

Федерация удостоверений

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

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

Брокеры аутентификации

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

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

Краткое содержание

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

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

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

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

Книга — Решение задач управления идентификацией в современных приложениях