Привет! Меня зовут Юрий Гуз, я ведущий разработчик команды IAM в MWS Cloud Platform. Мы продолжаем цикл статей о том, как устроен IAM в нашем облаке. Сегодня поговорим о технологии, которая стирает границы между вашей корпоративной IT-инфраструктурой и MWS, — о федерации доступов или просто федерации.
Мы уже рассказывали в статье, как мы делаем IAM для облака MWS. И описали там один из способов зайти в наше облако — использование MTS ID. Способ надёжный и удобный, если MTS ID у вас, конечно, есть. А что, если ваш провайдер удостоверений — это ваш корпоративный Active Directory, Google Workspace или Keycloak? Вам ведь не хочется заводить каждому сотруднику ещё один аккаунт, плодить лишние пароли и ломать уже выстроенные процессы с двухфакторной аутентификацией и ролевой моделью.
На этот случай у нас есть ответ — наша новая фича «Федерация». Она позволяет сотрудникам заходить в MWS с помощью их привычных рабочих учётных записей. Давайте разберёмся, как это работает и зачем нужно.
Немного теории
Что такое федерация
Федерация — если просто, «договор о доверии» между вашим провайдером удостоверений (IdP) и нашим облаком MWS Cloud Platform, который на схеме ниже выступает как поставщик услуг, SP.
После настройки этого «договора» ваши сотрудники получают доступ в консоль MWS, аутентифицируясь в вашей корпоративной системе. Им больше не нужны отдельные логины и пароли для нашего облака — мы полностью доверяем вашему IdP в этом вопросе.
А при чём тут SSO
Когда мы говорим о федерации, тут же всплывает термин SSO (Single Sign-On). Это не случайно — понятия тесно связаны, но есть и важная разница, объясню ниже.
SSO — это в первую очередь пользовательский опыт: возможность один раз войти в систему и получить доступ к нескольким приложениям без повторного ввода пароля. Чаще всего этот термин используют для доступа внутри одной организации, например, войдя в корпоративный портал, сотрудник получает доступ к CRM, почте и вики.
В то же время федерация — логическое развитие SSO, которая реализует тот же принцип единого входа, но уже между разными организациями и доменами. Если SSO работает в рамках одной компании, то федерация предоставляет сотрудникам доступ во внешние системы, как наше облако MWS Cloud Platform, без необходимости создания и запоминания нового пароля.
Для наглядности приведу аналогию: представьте себе SSO как единый пропуск для вашего офиса. Вы вошли с его помощью в здание — и он же открывает все двери внутри: в бухгалтерию, в кабинет разработчиков, на кухню. Это удобно, но работает только в пределах вашей компании.
Федерация — это тот же ваш пропуск, но который по договорённости открывает ещё и дверь в соседний бизнес-центр, наше облако MWS Cloud Platform. Вы выходите за пределы своей организации, но вам по-прежнему не нужен отдельный ключ.
Как это работает у нас
Если говорить технически, то федерация в MWS Cloud Platform — это ресурс, который вы создаёте в консоли со своими настройками и параметрами. Она существует в рамках организации — фундаментального ресурса, стоящего выше по иерархии. В одной организации может существовать множество федераций, каждую из которых пользователи могут использовать для входа в консоль.
С точки зрения системы доступа федерация работает как некий пул пользователей. Каждый, кто успешно зашёл через неё, попадает в одну из трёх категорий субъектов (принципалов), которым можно выдавать права:
Вся федерация — все пользователи, вошедшие через эту федерацию.
Конкретный пользователь — определяется своим уникальным идентификатором из вашего IdP.
Группа пользователей — все, у кого есть определённый атрибут, например все из отдела разработки.
В нашей системе такие принципалы обладают следующими идентификаторами:
// Вся федерация
iam/organizations/{название_организации}/userFederations/{название_федерации}
// Конкретный пользователь
iam/organizations/{название_организации}/userFederations/{название_федерации}/subjects/{идентификатор_пользователя}
// Группа пользователей по атрибуту
iam/organizations/{название_организации}/userFederations/{название_федерации}/attributes/{имя_атрибута}/value/{значение_атрибута}
К каждой федерации можно привязать один или несколько провайдеров. Это ещё один ресурс, отвечающий за подключение к вашему конкретному IdP, например Active Directory через SAML 2.0 или Keycloak через OIDC. Провайдеров может быть несколько.
Если федерация — это логическая группа пользователей из вашей организации, то провайдер — это технический мост между вашим IdP и нашим облаком. Именно он определяет, как именно будет проходить аутентификация. При создании провайдера вы можете выбрать один из популярных протоколов — OpenID Connect или SAML 2.0.
Пользовательские данные — важная составляющая всей системы федерации, и в зависимости от типа протокола, для которого будет настроен тот или иной провайдер, мы будем получать эти данные по-разному. К примеру, для OIDC-провайдеров большую часть информации мы берём из ID-токена или через запрос к userinfo API. Для провайдеров, настроенных на работу с SAML, мы используем блок assertions. Всё строго по стандартам, без самодеятельности.
А как мы используем эти данные? Тут всё просто. При создании провайдера мы предоставляем возможность настроить так называемый маппинг атрибутов, который нужен для соответствия ваших атрибутов на наши, используемые в IAM-системе облака.
Например, у нас есть обязательный атрибут mws.subject — уникальный идентификатор пользователя в MWS. Именно по нему мы определяем, кто вошёл в систему, кому выдавать права и как вести аудит. Вы можете маппить на него любое уникальное значение из вашего IdP: внутренний UUID, email или логин — как вам удобно.
Также можно настроить передачу дополнительных атрибутов — они помогут гибко управлять доступом через ABAC-модель и настраивать правила входа, например запретить доступ для сотрудников из определённого департамента.
А что с пользователями
Одной из главных дилемм при проектировании такой системы, как работать с пользователями, где их хранить и нужно ли их синхронизировать между источниками данных во внешнем IdP и в нашем облаке.
Начнём с последнего вопроса. При поиске решения данной задачи мы взяли на рассмотрение две модели — sync и syncless: с синхронизацией и без синхронизации соответственно. При выборе модели мы учитывали всё: удобство работы, синхронизацию пользовательских данных, вопросы аудита и возможность вписаться в уже существующую архитектуру MWS.
Модель Sync предполагает, что данные о пользователях из вашего IdP синхронизируются с данными в нашем облаке. Это даёт возможность заранее проставить им права, вести аудит и быстро проверять доступ.
Но эта модель создаёт сложности: нужно постоянно следить за изменениями во внешней системе, которую мы не контролируем, и решать, что делать, когда один и тот же пользователь приходит из разных провайдеров с разными данными. Риск рассинхронизации в такой схеме всегда высок, а для IAM подобное является очень опасным местом. Хотя есть готовые решения вроде SCIM, мы сочли этот подход слишком сложным и ресурсоёмким.
Модель Syncless — это подход «на лету». Данные о пользователе запрашиваются только в момент его входа и привязываются к сессии пользователя. В системе не хранится постоянной сущности «пользователь» — вместо этого информация из токена (OIDC) или утверждений (SAML) напрямую определяет, кто есть кто. На основе этих данных мы выписываем наш IAM-токен и далее в реальном времени через механизм ABAC вычисляем права доступа данного принципала.
Этот подход избавляет нас от проблем синхронизации и гарантирует, что любое изменение прав в вашем IdP мгновенно отразится на доступе пользователя в MWS при следующем перелогине в консоль. Всё, что для этого требуется, — гибко настроить маппинг а��рибутов для каждого провайдера, указав, какой атрибут использовать как уникальный идентификатор, а какие — для определения членства в группах. Таким образом, один и тот же пользователь, войдя через разные клиенты (OIDC / SAML), может получать разный набор прав в зависимости от набора атрибутов.
Если кратко подытожить всё вышесказанное, то процесс аутентификации через федерацию в MWS происходит следующим образом:
Инициация. Пользователь нажимает «Войти» в консоли MWS.
Перенаправление. Его перебрасывает в ваш корпоративный IdP, где он проходит аутентификацию (логин/пароль, 2FA).
Обмен данными. MWS получает данные пользователя из токена или assertions, в зависимости от выбранного протокола (OIDC/SAML).
Маппинг. Данные преобразуются в атрибуты MWS через настроенные правила.
Создание сессии. В MWS создаётся сессия пользователя, которая хранит контекст атрибутов для дальнейшего их использования в процессе авторизации в облаке.
И для чего это нужно
Реализация федеративных доступов — это не просто галочка в списке фич для нашего облака, а мощный инструмент, который решает конкретные бизнес-задачи и значительно упрощает жизнь IT-отделам компаний наших клиентов, а именно:
Централизованное управление доступом. Выдать/изменить права можно в одном-единственном месте. То же самое работает и в обратную сторону — к примеру, в случае увольнения сотрудника можно выключить его учётку в вашем IdP, после чего он автоматически теряет доступ к консоли MWS. Больше никаких «а мы забыли его удалить из облака». Риск утечки данных минимален.
Соответствие требованиям безопасности. Все правила безопасности (сложные пароли, 2FA) можно настроить один раз в вашем IdP. Наше облако им безоговорочно верит. Проверяющим нужно смотреть только одну систему, не более. Удобно, не правда ли?
Повышение продуктивности работы сотрудников. Сотрудникам не придётся заводить новые аккаунты, тратить время на запоминание и сброс новых паролей.
Заключение
Мы разобрали, как устроена федерация в MWS: от выбора протоколов и маппинга атрибутов до реализации модели Syncless. Это решение позволяет компании использовать облако MWS Cloud Platform как естественное расширение вашей IT-инфраструктуры — без лишних учётных записей и с сохранением всех корпоративных политик безопасности.
Что дальше?
Федерация — это большой и важный шаг в развитии IAM нашего облака, но на этом мы не останавливаемся. В планах — расширение наших возможностей ABAC, более глубокая интеграция с корпоративными системами и, конечно, постоянная работа над безопасностью и удобством. Сейчас этот сервис в стадии preview и доступен пользователям по запросу на сайте MWS Cloud Platform. К концу октября опубликуем документацию, обновим статью и оставим ссылку на док. А в следующих статьях перейдём к практике — подробно разберём, как настроить федерацию для вашего IdP. Оставайтесь на связи!