Keycloak вместо Microsoft ADFS: сами используем и вам советуем

Оба сервиса обеспечивают централизованный безопасный вход в приложения с возможностью единого входа (Single Sign-On, SSO). То есть пользователь единожды вводит свой пароль, после чего при переходе между сервисами система сразу его узнает. Очень нужная опция, когда речь идет об экосистемах продуктов – мы, как правило, именно такие и создаем.

Наш опыт с ADFS

В 2014-2015 годах, когда мы строили свои первые корпоративные приложения, ADFS представлял собой оптимальное решение с точки зрения цены и качества. Но прошло почти 10 лет, и ситуация на рынке технологий довольно сильно поменялась. Сейчас разработчики помещают приложения в облака, используют контейнеры, предъявляют новые требования к гибкости и отказоустойчивости.

Версия ADFS, с которой работаем мы, к этим условиям приспособлена плохо. Решение работает на базе устаревшего протокола SAML, поддержка актуального протокола OpenID Connect реализована только в новых версиях. Обновляться в нынешних условиях – нецелесообразно, учитывая, что речь о продукте Microsoft.

В силу своей родословной сервис накладывает технологические ограничения на работу со сторонними модулями – нельзя просто взять и интегрировать продукт с любым удобным Identity-провайдером. И что касается мобильных приложений, ADFS тоже работает не так гладко, как хотелось бы. И с отказоустойчивостью проблемы.

В общем, все подталкивает к тому, чтобы искать альтернативное решение.

Альтернативное решение

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

С прошлого года мы стали знакомиться с этими возможностями на практике – в наших новых продуктах для авторизации используется сервер Keycloak, который реализует OpenID Connect. Опыт сугубо положительный, и на сегодняшний день у нас уже готова дорожная карта для бесшовной миграции с ADFS на Keycloak.

К карте вернемся ниже, а пока чуть подробнее о том, что нам понравилось больше всего:

Полная свобода действий – можно использовать стороннюю базу пользователей, можно разместить ее в Keycloak, можно комбинировать данные из нескольких источников. То есть после авторизации в каком-либо приложении, система может обогащать профиль пользователя информацией, которую она получает от всех сервисов экосистемы.
Гибкость и контейнеризация – нет необходимости «знакомить» приложение с сервером авторизации, настраивать логику специально для работы с Keycloak (как оно было с ADFS). По сути, у вас появляется дополнительный слой абстракции, который обеспечивает вход пользователей. При необходимости можно вообще менять сервисы авторизации практически на лету, не погружаясь в код основного продукта.
Отказоустойчивость, масштабируемость, High Availability – Keycloak отлично справляется с высокими нагрузками, а для многих наших продуктов это имеет ключевое значение. Если у системы продажи билетов ломается авторизация, заказчик начинает терять живые деньги. Keycloak от таких неприятностей защищает.
Независимость ПО – отчасти уже говорили выше, но этот важный момент стоит повторить. Keycloak не требует ни Windows-окружения, ни Active Directory, ни доменного контроллера от Microsoft.
Удобно для пользователей – автоматическое продление сессий, возможность использования одноразовых СМС-кодов для двухфакторной аутентификации и т.д.
Удобно для разработчиков и администраторов – управлять пользователями можно через веб-консоль, нет дублирования пользовательских учетных записей, легко интегрироваться с любой инфраструктурой, просто организовывать DEV- и TEST-окружения.

Переходим Active Directory на Keycloak

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

Мы спланировали его перевод на Keycloak таким образом:

На первом этапе параллельно с существующей архитектурой появляется новая на основе Keycloak;
ADFS обращается к Keycloak как к Identity-провайдеру;
Keycloak в свою очередь обменивается данными со службой каталогов;
Когда готовы все настройки, запущены кастомные страницы авторизации и т.д, мы начинаем переключать приложения на Keycloak – одно за другим, все 40+ сервисов;
На завершающих этапах мигрируем пользователей и группы из AD и отключаем старую логику.

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