Единый вход (SSO) - это мечта любого безопасника и админа. Отключил человека в одном месте - он потерял доступ ко всему: от почты до кофемашины. В мире Open Source королем SSO стал Keycloak. На бумаге это идеальное решение.
В реальности, когда вы ставите Keycloak в энтерпрайз-инфраструктуру, вы сталкиваетесь с тремя проблемами: он тяжелый, он сложный, и ваш софт слишком стар для него.
Мой опыт внедрения и архитектурные паттерны, которые спасают, когда «1С» не понимает, что такое OAuth2.
1. Java-монстр и ресурсы
Первое, что нужно принять: Keycloak - это не легкий Go-бинарник. Это Java (JBoss/WildFly под капотом).
- Память: Не пытайтесь запустить его на 512Mb RAM. Ему нужен гигабайт только чтобы «прокашляться» на старте. В проде закладывайте минимум 2-4 ГБ на инстанс.
- Startup time: Он не стартует мгновенно. Это важно учитывать в Kubernetes при настройке
livenessProbe, иначе оркестратор будет убивать контейнер в бесконечном цикле, пока тот грузит классы.
2. Проблема «Глухого Легаси» (Identity Aware Proxy)
Это главная инженерная боль. Современный софт (Grafana, Gitlab, Nextcloud) нативно умеет OIDC (OpenID Connect) или SAML. Вы просто вбиваете Client ID / Secret, и магия работает.
Однако, в компании всегда есть «Зоопарк Юрского периода»: самописные админки на PHP 5.x, старые ERP, Jenkins без плагинов или, классика жанра, 1С. Они ничего не знают про токены, Redirect URI и OIDC. Они понимают только Basic Auth или вообще ничего.
Решение: Паттерн Identity Aware Proxy (IAP) Мы не учим старый софт новой аутентификации. Мы ставим перед ним охранника.
Схема: User -> Oauth2-Proxy (Nginx) -> Legacy App
- Пользователь стучится в легаси-приложение.
- Стоящий перед ним OAuth2-Proxy (легкий сервис на Go) видит, что куки нет, и перенаправляет юзера в Keycloak.
- Пользователь логинится в Keycloak.
- Keycloak возвращает юзера обратно с токеном.
- Proxy проверяет токен, извлекает из него Email или Username и пробрасывает их в легаси-приложение через HTTP-заголовки (например,
X-Forwarded-User). - Легаси-приложение просто доверяет заголовку (так как доступ к нему закрыт периметром сети) и пускает юзера.
Это единственный рабочий способ закрыть SSO-контуром вообще всё, включая древние монолиты. Если знаете другие способы, напишите :)
3. Кластеризация и Infinispan
Одиночный Keycloak - это точка отказа, но поднять кластер Keycloak - это отдельный квест. Проблема не в базе данных (Postgres отлично шарится). Проблема в кешах. Keycloak хранит сессии, токены и данные аутентификации в оперативной памяти (Infinispan).
Если у вас два инстанса Keycloak, и они не «видят» друг друга, юзер залогинится на Ноде-1, а следующий запрос прилетит на Ноду-2, которая ничего про него не знает. Результат: постоянные "разлогины".
Грабли: В Docker/K8s стандартный механизм discovery через Multicast (UDP) часто не работает.
Решение: Обязательно настраивайте JDBC_PING (связь через базу данных) или KUBE_PING (через API Kubernetes), чтобы ноды могли найти друг друга и синхронизировать кеш.
Итог
Keycloak - мощнейший комбайн. Но чтобы он ехал, а не давил вас:
- Не жалейте RAM.
- Используйте OAuth2-Proxy для всего, что не умеет OIDC нативно.
- Внимательно курите мануалы по Infinispan, если делаете HA.
Это больно настраивать один раз, но это окупается, когда вам нужно заблокировать уволенного сотрудника одной кнопкой, а не бегать по 15 админкам.