Что такое Federated Identity Management?

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

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

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

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

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

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

• возможные сервисные издержки.

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

Сценарий использования: Федеративный единый вход (Federated Single Sign-On)

Различают два типа единого входа: тот, который применяется для приложений внутри одной организации, и тот, который действует между организациями. Первый обычно называют просто Single Sign-On, иногда — «корпоративный единый вход» (Enterprise Single Sign-on). Второй подпадает под понятие Federated Single Sign-On (FSSO).

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

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

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

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

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

Федеративный единый вход (Federated Single Sign-on) позволяет совместно использовать учетные данные для входа за пределами границ компании. Как таковой он обычно опирается на крупную, хорошо зарекомендовавшую себя структуру с широким уровнем доверия — например, Google, Microsoft или Amazon. Даже небольшое приложение может быть относительно легко дополнено опцией «Войти через Google», предоставляя пользователям простой способ входа, при котором конфиденциальная информация остается в руках крупной организации.

Реализация Federated SSO

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

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

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

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

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

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

Поскольку это простое решение, большинство компаний сегодня выбирают облачный поставщик идентификации в рамках SaaS-предложения — как для Enterprise SSO, так и для Federated 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)