Централизованная авторизация

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

Почему LDAP уже недостаточно

LDAP (Lightweight Directory Access Protocol) — традиционная база для управления пользователями и группами в корпоративной среде. Он лежит в основе Active Directory и OpenLDAP, обеспечивает базовую идентификацию и разграничение прав.

Однако с ростом количества сервисов и усложнением процессов появляются ограничения:

• Пользователь должен быть заведен заранее.
• Отсутствует нативная поддержка SSO.
• OpenLDAP требует ручной и тонкой настройки.
• Active Directory внедрил собственные протоколы (Kerberos, NTLM), усложнив сценарии гибридной интеграции.
• Синхронизация групп происходит с задержкой и без событийной модели.

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

Keycloak: гибкая прослойка между LDAP и современными сервисами

Keycloak — это open source-сервер аутентификации, который позволяет строить централизованную модель доступа для широкого круга сервисов. Он умеет подключаться к LDAP, выступать как провайдер OpenID Connect, реализовывать политики 2FA, управлять сессиями и ролями.

В большинстве случаев Keycloak применяют там, где:

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

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

Ниже — базовая схема архитектуры авторизации с использованием Keycloak как прослойки между LDAP и корпоративными сервисами. Она отражает поток аутентификации и авторизации в типичной инфраструктуре.

OpenID Connect как унифицированный протокол доступа

OpenID Connect (OIDC) — это расширение протокола OAuth2, обеспечивающее аутентификацию. Он получил широкую поддержку во многих корпоративных системах: GitLab, Grafana, Kubernetes, ArgoCD и др.

Преимущества OIDC:

• Поддержка SSO.
• Возможность работы с клиентами (разграничение по ролям, scope, claims).
• Серверное хранение прав (устойчивость к лимитам токенов).
• Масштабируемость и отказоустойчивость.

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

Практические сценарии: Jira, Confluence, GitLab

Что с безопасностью: Kerberos и Radius

Kerberos используется в доменных структурах и обеспечивает безопасную аутентификацию без передачи пароля. Radius применяется для контроля доступа на сетевом уровне (VPN, Wi-Fi).

Keycloak не заменяет эти протоколы, но может дополнять их:

• использовать внешние IDP с Kerberos;
• управлять сессиями независимо от сетевого уровня;
• предоставлять OIDC-интерфейс для сервисов, не поддерживающих Kerberos/Radius.

Это повышает гибкость и расширяет архитектурные сценарии.

Администрирование и реальные ограничения

Внедрение Keycloak и переход на централизованную модель не отменяет административной работы:

• Доступы по-прежнему регулируются через заявки.
• Группы требуют регулярной ревизии.
• Отказ от ручного управления невозможен без зрелых процессов и политик.

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

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

Масштабирование: как работает Keycloak в больших организациях

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

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

Важно понимать, что Keycloak — это не «внедрили и забыли», а часть архитектуры, которая требует сопровождения, развития и встраивания в процессы.

Что это даёт бизнесу

• Снижение административной нагрузки. Доступ управляется централизованно, а не в каждом сервисе по отдельности.
• Повышение безопасности. Включение 2FA, контроль токенов, ограничение по времени сессий.
• Масштабируемость. Легче подключать новые сервисы и команды.
• Управляемость. Права и роли настраиваются через интерфейс, с возможностью делегирования.
• Гибкость. Возможность адаптировать модель доступа под контексты, клиентов и процессы.

Что дальше

Если вы внедряете Keycloak, переходите на SSO или ищете способ организовать доступ через OpenID Connect — мы можем помочь. В Etence мы:

• проектируем архитектуру авторизации;
• интегрируем Keycloak с LDAP, GitLab, Jira, Confluence и другими системами;
• адаптируем подход под вашу зрелость, бюджет и ограничения;
• сопровождаем внедрение и передаём шаблоны, практики, документацию.

Если тема близка — напишите нам. Посмотрим, как сделать управление доступом устойчивым, гибким и прозрачным именно для вашей команды.

13.06.2025