Единая авторизация с Keycloak, OpenID Connect и LDAP: что подготовить

Единая авторизация нужна, когда доступ к нескольким системам должен управляться централизованно: пользователи входят один раз, права выдаются через роли и группы, а сервисы доверяют общему провайдеру идентификации. Keycloak часто используют как прослойку между LDAP/Active Directory и современными приложениями, которые работают через OpenID Connect или SAML.

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

• у компании несколько внутренних систем: Jira, Confluence, GitLab, CRM, порталы, админки или собственные сервисы;
• пользователи и группы уже живут в LDAP или Active Directory;
• нужно единое место для входа, MFA, политик паролей, сессий и аудита;
• новые приложения должны подключаться через OpenID Connect, OAuth 2.0 или SAML;
• важно быстро отзывать доступы при смене роли или увольнении сотрудника;
• есть требования безопасности, аудита или разделения контуров.

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

Не стоит внедрять Keycloak как “магический слой” поверх хаотичных прав. Если в компании не согласованы роли, группы, владельцы сервисов и правила выдачи доступа, SSO только сделает эту путаницу централизованной.

• источник пользователей: LDAP, Active Directory, HR-система или локальные учетные записи;
• группы, роли, атрибуты пользователей и правила их обновления;
• список подключаемых сервисов и поддерживаемые ими протоколы;
• требования к MFA, паролям, срокам сессий, refresh tokens и logout;
• контуры: dev, test, prod, внешние пользователи, подрядчики, администраторы;
• модель администрирования: кто создает клиентов, выдает роли и разбирает инциденты;
• требования к журналированию, резервному копированию, мониторингу и отказоустойчивости.

В простой схеме Keycloak подключается к LDAP/AD как user federation, а приложения становятся клиентами Keycloak. Для web-приложений обычно используют OpenID Connect authorization code flow. Для старых корпоративных систем может понадобиться SAML. Для сервис-сервис взаимодействия отдельно проектируют client credentials, service accounts и scope.

Важно заранее решить, где живет правда о пользователе. LDAP/AD часто остается источником учетных записей и групп, а Keycloak отвечает за протоколы, токены, клиентов, маппинг ролей, MFA и политики сессий.

Эти вопросы лучше разобрать до внедрения, потому что именно на них чаще всего ломаются SSO-проекты с LDAP, AD и несколькими сервисами.

Почему LDAP или AD недостаточно для SSO

LDAP и AD хорошо хранят пользователей, группы и атрибуты, но приложениям обычно нужен web/app-level SSO: токены, claims, scopes, сессии, MFA, logout, role mapping и аудит входов. Keycloak становится слоем между каталогом и сервисами: читает пользователей из LDAP/AD, а приложениям отдает OIDC/OAuth2 или SAML.

Keycloak заменяет AD?

Нет. AD или OpenLDAP остаются источником учетных записей, групп и корпоративных атрибутов. Keycloak дополняет их как identity broker и access layer. OpenLDAP можно использовать как user federation source, но он не дает всей доменной инфраструктуры AD: Kerberos/NTLM, group policy и привычных enterprise-механик Windows-среды.

Какие сущности Keycloak нужно понимать

• Realm — изолированная область пользователей, clients, ролей и настроек входа.
• Client — приложение или сервис, который доверяет Keycloak и получает токены.
• Identity provider — внешний поставщик идентичности, например корпоративный IdP.
• User federation — подключение LDAP/AD как источника пользователей и групп.
• Authentication flow — порядок шагов входа: пароль, MFA, условия, redirects.
• Roles/groups — модель прав, которую затем нужно сопоставить с правами приложений.
• Token service и admin API — выдача токенов и управляемая автоматизация настроек.

Как сохранить стабильный идентификатор пользователя

До запуска нужно решить, какой LDAP/AD атрибут станет устойчивым идентификатором. В AD часто используют `objectGUID`; затем через attribute mapping его связывают с пользователем Keycloak и проверяют, как формируется `sub` в токене. Ошибка на этом уровне приводит к дубликатам пользователей, потере истории и сломанным правам после миграции.

Когда нужен SAML вместо OIDC

OIDC обычно удобнее для современных web/mobile/API-сервисов. SAML нужен, если корпоративное приложение или внешний сервис не поддерживает OIDC, но умеет принимать SAML assertions. В таком случае Keycloak может выступать SAML Identity Provider или broker, а LDAP/AD остается источником пользователей.

Что с RADIUS

RADIUS не является основным протоколом Keycloak для web/app SSO. Возможны адаптеры, прокси и обходные схемы, но их нужно рассматривать как отдельный edge-case: проверить поддержку клиента, безопасность, MFA, аудит и последствия для сопровождения.

Примеры

• Jira и Confluence. Direct LDAP может дать группы, но не всегда решает SSO, единый logout, MFA и понятное сопоставление ролей между сервисами. Через Keycloak проще централизовать вход и правила доступа.
• GitLab. При прямом LDAP часто возникают задержки синхронизации групп и разная логика ролей. OIDC через Keycloak позволяет передавать claims, группы и роли в токене и централизовать аудит входов.

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

• HR event. Определите, откуда приходит событие о найме, переводе, отпуске или увольнении.
• LDAP/AD. Проверьте, где создается пользователь, какие группы и атрибуты считаются источником истины.
• Keycloak roles/groups. Опишите, какие LDAP/AD группы мапятся в роли, groups или claims Keycloak.
• Service access. Проверьте, как Jira, Confluence, GitLab и другие сервисы читают claims/scopes и применяют локальные права.
• Revoke. Отдельно проверьте отключение пользователя, истечение сессий, отзыв refresh tokens и аудит доступа после увольнения.

Также проверьте стабильный идентификатор пользователя, сценарии MFA, резервный admin-доступ, журналы входа, настройки realm, clients, redirect URI и порядок изменения ролей.

Для production-контура нужно проектировать Keycloak как критичный инфраструктурный сервис: база данных, резервное копирование, обновления, TLS, reverse proxy, health checks, мониторинг, ограничения административного доступа и порядок восстановления. Отдельно проверяют настройки токенов, redirect URI, CORS, client secrets, MFA, brute-force protection и аудит событий.

Kerberos, Radius и другие механизмы могут дополнять контур, но их нужно рассматривать через конкретные сценарии: доменный вход, VPN, сетевые устройства, legacy-системы или требования службы безопасности.

• подключить сервисы к SSO без согласованной модели ролей;
• выдать права через группы, смысл которых никто не поддерживает;
• оставить широкие redirect URI и слабые client secrets;
• не проверить logout, отзыв токенов и увольнение пользователя;
• не настроить резервное копирование базы Keycloak;
• не разделить dev/test/prod realms или клиентов;
• обновлять Keycloak без тестового контура и rollback-плана;
• не назначить владельца эксплуатации SSO.

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

• проверить доступы к коду, CI/CD и окружениям;
• согласовать интеграции информационных систем;
• проверить инфраструктуру, доступы и процессы сопровождения.