В корпоративной среде пользователи заведены не в вашей базе, а в едином каталоге компании, и логинятся один раз при входе в систему. За этим обычно стоят две старые, но живучие технологии — LDAP и Kerberos. Разберём, что это, зачем и как они стыкуются с современным приложением на OAuth2/JWT через Keycloak.

LDAP — каталог пользователей

LDAP (Lightweight Directory Access Protocol) — протокол доступа к каталогу: древовидной базе пользователей, групп и их атрибутов (логин, email, отдел, членство в группах). Самая распространённая реализация — Active Directory от Microsoft; есть и открытые (OpenLDAP, FreeIPA).

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

Kerberos — билетный SSO

Kerberos решает другую задачу: единый вход (Single Sign-On) внутри домена. Пользователь один раз аутентифицируется при входе в рабочую станцию и дальше заходит во внутренние сервисы без повторного ввода пароля.

Идея — в билетах. Центр (в Active Directory это контроллер домена) выдаёт пользователю зашифрованный билет, которым тот молча доказывает свою личность сервисам. Пароль по сети при этом не ходит. В вебе Kerberos прокидывается в браузер через механизм SPNEGO: браузер автоматически предъявляет билет сайту во внутренней сети — пользователь просто открывает страницу и уже залогинен.

Как это связать с современным приложением

Писать поддержку LDAP и Kerberos в каждом сервисе — плохая идея. Современный подход — поставить между корпоративным каталогом и приложениями Keycloak (или другой identity provider), который берёт эту интеграцию на себя:

  • Федерация LDAP. Keycloak подключается к Active Directory/LDAP и видит корпоративных пользователей как своих — не копируя пароли. Вход проверяется в каталоге, а наружу Keycloak выдаёт стандартный OAuth2/OIDC-токен.
  • Kerberos / SPNEGO. Keycloak умеет принимать Kerberos-билет из браузера и по нему сразу выдавать токен — получается сквозной корпоративный SSO без экрана логина.

Для вашего Spring-сервиса это означает, что ничего кроме привычного JWT знать не нужно: сервис по-прежнему валидирует токен от Keycloak, а откуда Keycloak взял пользователя — из формы логина, из LDAP или по Kerberos-билету — деталь, скрытая за identity provider.

Коротко

  • LDAP — каталог пользователей и групп компании (чаще всего Active Directory); единый источник правды «кто есть кто».
  • Kerberos — билетный Single Sign-On в домене: один вход, дальше — без повторного пароля; в вебе прокидывается через SPNEGO.
  • Не встраивайте их в каждый сервис — поставьте Keycloak между каталогом и приложениями.
  • Keycloak делает федерацию LDAP (видит корпоративных пользователей) и принимает Kerberos-билеты, а наружу отдаёт стандартный OAuth2/JWT.
  • Приложению достаточно валидировать JWT — источник аутентификации скрыт за identity provider.

Что почитать дальше

  • Что такое Keycloak — зачем нужен identity provider и что он берёт на себя.
  • OAuth2 и OIDC — стандартные протоколы, в которые Keycloak «переводит» корпоративный вход.
  • Keycloak и Spring Security — как сервис валидирует токен от Keycloak.