Что такое федеративное управление удостоверениями?

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

Определение федеративного управления идентификацией

Управление идентификацией и доступом (IAM) – это широкая область, охватывающая цифровые идентификаторы и управление доступом. Федеративное управление идентификацией (или FIM) – это категория IAM, которая фокусируется на безопасном обеспечении единого события аутентификации для охвата нескольких взаимодействий или обмена информацией об идентификации. Другими словами, FIM позволяет множеству сервисов совместно использовать единую цифровую идентификацию. Практическим примером использования FIM может служить вход в Twitter с использованием вашей учетной записи Google.

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

• повышенная архитектурная сложность,

• привязка к определенному поставщику и

• возможные затраты на обслуживание.

Федеративное управление идентификацией иногда путают с единым входом (SSO). Строго говоря, SSO – это функция FIM и один из его основных вариантов использования, который мы рассмотрим ниже. И еще одно замечание: тема Self-Sovereign Identity (или децентрализованной идентификации) – это другая история.

Вариант использования: (федеративный) единый вход

Различают два типа единого входа: для приложений внутри одной организации и для приложений, охватывающих несколько организаций. Первый обычно называют просто единым входом, иногда “корпоративным единым входом”. Второй подпадает под понятие федеративного единого входа (FSSO).

Высокоуровневая архитектура, охватывающая обе формы SSO, выглядит следующим образом:

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

• создан самой организацией (например, с использованием Active Directory).

• предоставляется поставщиком идентификации в различной степени.

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

Федеративный единый вход позволяет совместно использовать учетные данные за пределами компании. Как таковой, он обычно опирается на крупную, хорошо зарекомендовавшую себя организацию с широким уровнем доверия – например, Google, Microsoft или Amazon. Даже небольшое приложение может относительно легко добавить опцию “Войти через Google” и предложить пользователям простой способ входа, при котором конфиденциальная информация остается в руках крупной организации.

Реализация федеративного SSO

Построение решения Federated SSO зависит от конкретных требований. Однако общие шаги при этом идентичны:

• Настройка поставщика идентификации: либо вы предоставляете централизованную инфраструктуру идентификации, либо создаете учетную запись у поставщика федеративной идентификации (Google, Microsoft, Okta). Также возможен гибридный вариант.

• Заполнение поставщика информацией о приложении: так вы настраиваете поставщика идентификации и создаете основу для подключения приложений к поставщику.

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

• Настройка приложений: в код приложения добавьте зависимости для аутентификации и взаимодействия со службой поставщика идентификации.

• Интеграция новой аутентификации: с настроенной службой SSO у ваших пользователей есть возможность аутентифицироваться. Это также работает “прозрачно”: приложения автоматически распознают и аутентифицируют пользователей с живой сессией в другой службе.

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

Реализация протоколов SSO

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

• SAML – это XML-протокол, который часто используется в компаниях для поддержки Enterprise SSO или для переключения между различными поставщиками бизнес-услуг. Он также может использоваться для общего обмена идентификационной информацией, включая Federated SSO (если поставщик идентификации это поддерживает).

• OAuth 2.0 – это протокол аутентификации, который позволяет совместно использовать данные ресурсов между поставщиками на основе согласия пользователя. Oauth фокусируется на совместном использовании аутентификации между службами без предоставления учетных данных.

• OIDC (OpenID Connect) – это уровень, построенный на OAuth 2.0, который обычно используется для социальных логинов (например, “Войти через GitHub”). OIDC включает в себя некоторые расширения по сравнению с OAuth, включая Identity Assertions, Userinfo API и Standard Discovery – стандартизированные механизмы для безопасного предоставления и использования информации об идентификации.

Эти протоколы используются отдельно или в сочетании с другими технологиями. Например, JSON Web Token можно использовать для инкапсуляции информации о токене учетных данных OAuth 2.0 в более безопасном формате.

К счастью, процесс реализации этих протоколов хорошо документирован и поддерживается множеством технологических стеков. Большая часть работы инкапсулируется абстракциями более высокого уровня на многих языках и фреймворках. Spring Security, например, предлагает поддержку SSO, как и Passport в экосистеме NodeJS/Express. (fm)

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