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

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

В такой схеме Keycloak обычно выступает как identity provider или broker, OpenID Connect — как протокол подключения современных приложений, а LDAP или Active Directory — как каталог пользователей и групп. Перед внедрением важнее всего согласовать модель доступа, а не только установить сервис.

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

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

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

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

• источник пользователей: LDAP, Active Directory, HR-система или локальные учетные записи;
• группы, роли, атрибуты пользователей и владельцы этих справочников;
• список приложений-клиентов, их redirect URI, окружения и ответственные команды;
• требования к SSO, MFA, срокам жизни токенов, сессиям и logout-сценариям;
• правила аудита, журналирования, резервного копирования и восстановления;
• порядок выдачи, изменения и отзыва доступа при смене роли или увольнении сотрудника.

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

Decision flow ниже помогает выбрать стартовую модель: встроенная авторизация, Keycloak поверх LDAP/AD, отдельный realm для группы систем или более строгий контур с MFA, аудитом и разделением окружений.

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

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

Эти вопросы лучше разобрать до внедрения, потому что именно на них чаще всего ломаются 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, группы и роли в токене и централизовать аудит входов.

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

Для 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.

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