Централизованная аутентификация и SSO на базе Keycloak для корпоративных систем

Исходная инфраструктура

В инфраструктуре компании работало около 50–60 систем, каждая со своей историей внедрения, собственным поставщиком и правилами интеграции.

Разнородность систем

Сотрудники делились на два типа: офисные и ресторанные.

Офисные сотрудники находились в Active Directory, и корпоративные системы уже были к нему подключены. В этой части инфраструктура оставалась управляемой. С ресторанными сотрудниками ситуация была иной. Здесь сложилось два подхода, и оба создавали проблемы.

Первый — общие обезличенные учетки из Active Directory. Один логин и пароль на весь ресторан или смену: кассир, администратор и управляющий заходили под одними и теми же данными. Кто именно работал в системе в конкретный момент — неизвестно, полноценный аудит действий в таких условиях невозможен.

Второй — часть систем создавала собственную базу пользователей. Поставщик подключался к ERP (Корпоративная система, в которой HR-отдел ведет учет и управление данными о сотрудниках), забирал нужный ему список сотрудников и хранил их у себя: свои логины, свои пароли, своя логика того, кого считать активным сотрудником, а кого — уволенным. В итоге у каждой такой системы был свой срез сотрудников, и никто не сверял эти списки между собой.

В результате было сложно ответить на базовые вопросы:

• кто и к каким системам имеет доступ 
• закрыты ли учетные записи уволенных сотрудников 
• как именно работает конкретная интеграция 

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

Сложность для пользователей и администраторов

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

Администратору, которому требовалось закрыть доступ уволенному сотруднику, приходилось обращаться к каждому поставщику системы отдельно. Единого инструмента управления доступами не существовало.

Архитектура решения: аутентификация и SSO на базе Keycloak

В основе решения — Keycloak, open-source платформа для централизованной аутентификации и авторизации.

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

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

• OAuth 2.0 
• OpenID Connect 
• SAML 

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

Единым источником данных о сотрудниках стала ERP-система. Из нее информация поступает в сервис синхронизации:

• для ресторанных сотрудников создаются учетные записи в FreeIPA 
• для офисных сотрудников основным каталогом остается Active Directory, который дополнительно обогащается данными из ERP 

Keycloak подключен к обоим каталогам через механизм федерации и выступает единой точкой входа для всех систем.

Второй фактор аутентификации реализован по-разному для разных категорий сотрудников:

• офисные сотрудники используют внешний MFA-сервис с push-подтверждением на телефоне 
• ресторанные сотрудники используют стандартный TOTP через приложение-аутентификатор 

Восстановление пароля происходит через второй фактор, если он настроен. Если MFA не подключен, используется SMS-код.

Особенности интеграции

Инфраструктура

Решение развернуто на трех нодах в разных дата-центрах. Keycloak работает в режиме active-active с общим распределенным кэшем Infinispan. FreeIPA работает в режиме multi-master репликации.

Система продолжает функционировать даже при отказе одного из дата-центров.

Два каталога — две истории

Офисные сотрудники уже существовали в Active Directory. Основная задача заключалась в обогащении каталога дополнительными атрибутами из ERP.

Для ресторанных сотрудников каталог FreeIPA создавался с нуля. Был разработан полноценный pipeline синхронизации, который включает:

• валидацию данных 
• нормализацию телефонных номеров 
• обработку дубликатов 
• защитные механизмы 
• детальную статистику по каждому запуску 

Кастомные расширения

Стандартного функционала Keycloak оказалось недостаточно, поэтому были разработаны собственные Java-расширения. Среди них:

• отправка и проверка SMS-кода при сбросе пароля с поддержкой разных SMS-провайдеров 
• проверка наличия настроенного MFA-устройства для выбора сценария восстановления доступа 

Также реализован кастомный authentication flow с логикой выбора второго фактора в зависимости от типа сотрудника. Форма входа стилизована под корпоративный интерфейс компании.

Подключение систем

Каждая система регистрируется в Keycloak как отдельный клиент — через OIDC или SAML, в зависимости от возможностей продукта. Для каждой системы проводились консультации по интеграции и настройке.

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

Параллельно с технической настройкой происходило поэтапное переключение систем.

Процесс внедрения и эксплуатация 

Поэтапное переключение систем

Внедрение проходило постепенно. Первыми подключались офисные системы, интегрированные с Active Directory. Сначала был проведен пилот на одном приложении, после чего схема подключения была масштабирована на остальные системы.

Ресторанные системы потребовали отдельного подхода. В первую очередь переключались системы, которые использовали общие ресторанные учетные записи из Active Directory. Для каждой системы был организован постепенный перевод сотрудников на персональные учетные записи — ресторан за рестораном, с обучением и инструкциями.

Такой подход позволил постепенно внедрять второй фактор аутентификации. Одновременный переход примерно 30 тысяч сотрудников на MFA был бы слишком сложным как для поддержки, так и для пользователей.

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

По мере того, как в системе полностью исчезали общие учетные записи, это становилось индикатором готовности. Значит сотрудники уже используют вход через Keycloak и можно переключать следующий слой систем.

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

Отказоустойчивость

Перед запуском было проведено комплексное тестирование отказоустойчивости трех кластеров:

• Keycloak 
• PostgreSQL 
• FreeIPA 

Проверялись сценарии отключения отдельных нод, потери связи между дата-центрами и недоступности базы данных. Во всех штатных сценариях система автоматически восстанавливалась примерно за 30 секунд. Пользовательские сессии при этом сохранялись.

Однако тестирование выявило и нестандартный сценарий. При временной потере связи между дата-центрами нода Infinispan после восстановления не всегда корректно возвращалась в кластер и могла считать себя координатором. Это приводило к рассинхронизации кэшей и ошибкам при обработке запросов. Проблема стабильно воспроизводилась, обновление версии Keycloak ее не решало.

В качестве временного решения был написан watchdog-скрипт на Python. Он отслеживает состояние кластера и при необходимости автоматически перезапускает контейнер без участия администратора.

Также проблема была зарегистрирована в репозитории Keycloak. Мы зарепортили эту проблему и команда Keycloak подтвердила наличие бага и включила исправление в roadmap.

Нагрузочное тестирование

Нагрузочные тесты проводились с использованием Yandex Tank. Тестировались сценарии входа пользователей с учетом OTP-аутентификации и обновления токенов.

Тесты запускались:

• из внутренней сети 
• из внешней среды через Яндекс Облако 

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

(Пример сбоя в момент нагрузочного тестирования. Оранжевые пики указывают на зависания в ответах и возникновение тайм-аутов через определенное время)

(Пример успешного прохождения нагрузочного тестирования. После устранения проблем балансировщика время ответа не превышало 60 мс)

Мониторинг

Состояние системы отслеживается через Grafana с использованием VictoriaMetrics и Loki. Настроены отдельные дашборды для компонентов:

• Keycloak 
• PostgreSQL 
• FreeIPA 
• etcd 

Логи хранятся 90 дней. Настроены алерты на ключевые события: от проблем с репликацией до превышения порога ошибок синхронизации.

(Дашборд мониторинга переключенных систем на Keycloak в Grafana.)

Что получили в итоге

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

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

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

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