Централизованная авторизация с Keycloak и OpenID Connect
Централизованная авторизация нужна там, где десятки сервисов и растущие требования к безопасности делают управление доступами хрупким. В материале показываем, как построить SSO на базе Keycloak и OpenID Connect с подключением LDAP/Active Directory и едиными ролями. Статья для архитекторов и ИТ-команд: разберём архитектуру, интеграции и практические настройки.
Почему LDAP уже недостаточно
LDAP — базовый протокол каталогов (Active Directory, OpenLDAP), который хранит учётные записи и группы и обеспечивает базовую аутентификацию и разграничение прав.
Однако при росте сервисов и гибридной инфраструктуре проявляются ограничения:
- Пользователь и его группы должны быть заведены и синхронизированы заранее.
- Нет нативного SSO для большинства веб-сервисов без дополнительных шлюзов.
- OpenLDAP требует ручной тонкой настройки и не даёт единого уровня политик.
- В AD доминируют Kerberos/NTLM, что усложняет веб-сценарии и гибридные интеграции.
- Синхронизация групп – с задержками, без событийной модели и fine-grained контролей.
В итоге доступы применяются неоперативно, SSO расползается по костылям, а архитектура становится хрупкой и дорогой в сопровождении.
Keycloak: гибкая прослойка между LDAP и современными сервисами
Keycloak – open-source IAM-сервер, который подключается к LDAP/AD, выступает провайдером OpenID Connect/OAuth 2.0/SAML, управляет сессиями, ролями и политиками (включая 2FA).
Keycloak применяют там, где нужно:
- дать SSO веб-сервисам без прямой поддержки LDAP;
- централизовать политики доступа и роли для разных систем;
- минимизировать ручное управление учётными записями и группами;
- разграничить клиентов/домены/контексты в одной инфраструктуре.
Keycloak не заменяет LDAP/AD, а надстраивается над ним — это шлюз авторизации с явным контролем и гибкой конфигурацией под сервисы.
Ниже — базовая схема архитектуры авторизации с использованием Keycloak как прослойки между LDAP и корпоративными сервисами. Она отражает поток аутентификации и авторизации в типичной инфраструктуре.
OpenID Connect как унифицированный протокол доступа
OpenID Connect (OIDC) – расширение OAuth 2.0 для аутентификации, широко поддерживаемое корпоративными системами (GitLab, Grafana, Kubernetes, Argo CD и др.).
Преимущества OIDC:
- Единый вход (SSO) для веб-приложений.
- Тонкая модель клиентов: scopes, claims, role-mapping.
- Серверная проверка прав (меньше зависимости от лимитов токена).
- Хорошая масштабируемость и отказоустойчивость через кластер Keycloak.
В Keycloak настраиваются клиенты OIDC: форматы токенов, маппинг атрибутов/ролей, валидация сессий и политики времени жизни.
Практические сценарии: Jira, Confluence, GitLab
Jira и Confluence
Jira умеет подключаться к LDAP/AD напрямую, но внешние группы редактировать нельзя, а синхронизация и кэш часто задерживают изменения.
Confluence часто берёт пользователей из Jira, и права фактически зависят от каталога и групп, видимых в Jira.
GitLab
GitLab поддерживает LDAP и OIDC; при LDAP-подключении типичны задержки синхронизации групп и неконсистентность ролей. Интеграция GitLab ↔ Keycloak по OIDC позволяет:
- не ходить в LDAP из GitLab;
- передавать роли и группы при логине;
- централизовать контроль доступа и аудит.
В результате снижается нагрузка на администраторов и ускоряется онбординг/оффбординг пользователей.
Что с безопасностью: Kerberos и Radius
Kerberos применяют в доменных средах для взаимной аутентификации без передачи паролей; RADIUS — на сетевом уровне (VPN, Wi-Fi).
Keycloak не заменяет Kerberos/RADIUS, а дополняет их на прикладном уровне:
- подключать внешние IdP с Kerberos;
- управлять прикладными сессиями независимо от сетевого уровня;
- давать OIDC-интерфейс сервисам без поддержки Kerberos/RADIUS.
Это повышает гибкость и расширяет архитектурные сценарии.
Администрирование и реальные ограничения
Внедрение Keycloak и централизованной модели не отменяет операционного администрирования:
- Доступы оформляются через заявки и регламенты.
- Группы и роли нуждаются в регулярной ревизии и чистке.
- Снижение ручных операций возможно только при зрелых процессах и политиках.
Ключ к устойчивости — повторяемые сценарии, прозрачные процессы и определённые роли администраторов, а не «полный автомат» любой ценой.
Чтобы обеспечить управляемость и предсказуемость доступа, важно рассматривать не только архитектуру, но и жизненный цикл учётной записи: от создания до удаления. Ниже — схема этого процесса в связке с HR-системой, LDAP и Keycloak.
Масштабирование: как работает Keycloak в больших организациях
Для десятков тысяч пользователей и множества доменов Keycloak выступает единым шлюзом авторизации. Он помогает:
- централизовать роли и права для разных площадок;
- разграничить клиентов/тенанты и контексты;
- снизить нагрузку на каталоги LDAP/AD;
- обеспечить отказоустойчивость через кластеризацию и горизонтальное масштабирование.
Keycloak — это не «внедрили и забыли», а живой компонент архитектуры, требующий мониторинга, обновлений и встраивания в процессы.
FAQ: ответы на частые вопросы по Keycloak, LDAP, AD и OIDC
Как связаны objectGUID из Active Directory и sub в Keycloak?
objectGUID — уникальный неизменяемый идентификатор объекта в Active Directory.
В Keycloak поле sub — это уникальный идентификатор пользователя, который передаётся сервисам в OIDC-токене.
Связь следующая: AD → Keycloak (User Federation) считывает objectGUID. Через User Attribute Mapper можно назначить objectGUID источником sub.
Это гарантирует, что sub не изменится при:
- смене логина.
- переименовании учётной записи.
- миграции домена или OU.
- изменении email.
Может ли Keycloak работать как Identity Provider по SAML при использовании LDAP/AD?
Да. Keycloak может быть не только OIDC-провайдером, но и SAML Identity Provider, даже если источником пользователей является LDAP/AD.
Сценарий:
- LDAP или AD → Keycloak (User Federation, синхронизация пользователей)
- Сервисы (Jira, Confluence, корпоративные порталы) → Keycloak по SAML 2.0
- Keycloak выдаёт SAML-assertion с атрибутами, ролями и группами.
Когда выбирать SAML:
- если сервис не поддерживает OIDC
- если требуются атрибуты в SAML assertion
- если в организации уже есть SAML-сервисы
Как работает Keycloak внутри?
Keycloak состоит из нескольких ключевых компонентов:
- Realms — изолированные домены пользователей и настроек;
- Clients — приложения, которые используют OIDC/SAML;
- Identity Providers — внешние источники аутентификации (AD, LDAP, SAML, OIDC);
- User Federation — синхронизация пользователей из LDAP/AD;
- Authentication Flows — цепочки логина (пароль, OTP, MFA);
- Roles / Groups — модель авторизации;
- Token Service — выдача OIDC-токенов (ID, Access, Refresh);
- Admin Console / Admin REST API — управление конфигурацией.
Процесс работы:
- Пользователь → логин в Keycloak;
- Keycloak → проверяет пользователя в AD/LDAP (или внешнем IdP);
- Keycloak → создаёт/обновляет локальный user object;
- Keycloak → выдаёт токен OIDC/SAML клиенту;
- Клиент → проверяет токен и назначает доступы.
Можно ли использовать RADIUS вместе с Keycloak?
Да, но косвенно. Keycloak не является RADIUS-сервером, однако работает через адаптеры.
Варианты:
- Keycloak → FreeRADIUS plugin
- Keycloak-RADIUS gateway
- RADIUS → Keycloak OIDC (для Wi-Fi/VPN)
Ограничения:
- MFA зависит от протокола (PAP/CHAP);
- Не все атрибуты корректно передаются;
- RADIUS остаётся на сетевом уровне, Keycloak — на прикладном.
Чем отличается прямая LDAP-аутентификация от OIDC через Keycloak?
LDAP/AD обеспечивает базовую проверку логина и пароля и отдаёт группы, но сам по себе не предоставляет современную модель SSO, токенов и ролей. При расширении количества сервисов это становится узким местом.
LDAP остаётся источником учётных записей, но роль центра авторизации и SSO лучше решается через Keycloak и OpenID Connect. Это снижает нагрузку на каталог, упрощает интеграции и даёт современный контроль доступов.
Может ли Keycloak заменить Active Directory?
Нет. AD остаётся каталогом, а Keycloak — прослойкой авторизации. Keycloak — это слой SSO, OIDC/SAML, ролей и токенов, а не каталог.
Можно ли использовать Keycloak и OpenLDAP вместо AD?
Да, Keycloak работает с OpenLDAP полностью.
Но ограничения:
- нет Kerberos;
- нет NTLM;
- нет доменной инфраструктуры;
- часть enterprise-сервисов требует AD.
Что это даёт бизнесу
- Снижение административной нагрузки. Меньше рутины.
- Повышение безопасности. Больше контроля и безопасности.
- Масштабируемость. Готовность к росту.
- Управляемость. Предсказуемость и управляемость.
- Гибкость. Адаптивность под контексты.
Что дальше
Если вы внедряете SSO на базе Keycloak и OIDC или хотите связать LDAP/AD с Jira, GitLab и другими сервисами — поможем спроектировать и внедрить решение под ваш контекст. Мы делаем архитектуру авторизации, интеграции и сопровождение с передачей регламентов и шаблонов.
Напишите нам – обсудим, как сделать доступы управляемыми и предсказуемыми.
13.06.2025 (обн. 06.11.2025, 17.11.2025)