Перейти к основному содержимому

Настройка OAuth и LDAP

Подключение корпоративного identity provider, mapping ролей, проверка входа и восстановления, разделение authentication и локальной authorization.

Корпоративная версия

OAuth и LDAP аутентифицируют человека через внешний identity source. CodeGraph по-прежнему владеет локальным пользователем, ролью, permissions, project scope, сессией, audit events и отзывом доступа. Группа identity provider не становится разрешением CodeGraph до применения одобренного mapping.

Выбор интеграции

Используйте OAuth/OIDC, когда провайдер поддерживает браузерный authorization-code flow и централизованную регистрацию клиента. LDAP или Active Directory подходят, когда directory bind и group lookup являются согласованным паттерном заказчика. Можно настроить оба способа, но для каждого нужны владелец, проверенный failure mode и recovery path.

Типизированная конфигурация находится в src/api/config.py, реализации — в src/api/auth/providers/oauth.py и src/api/auth/providers/ldap_auth.py.

Актуальные маршруты

Приложение публикует операции identity под /api/v1/auth:

Актуальные маршруты
Метод и маршрут Назначение
GET /api/v1/auth/oauth/providers Получить настроенные OAuth providers и start URLs.
GET /api/v1/auth/oauth/{provider} Начать authorization flow провайдера.
GET /api/v1/auth/oauth/{provider}/callback Проверить state, обменять code и создать локальную сессию.
POST /api/v1/auth/ldap Проверить LDAP credentials и сопоставить directory identity.
GET /api/v1/auth/ldap/status Узнать, настроен и доступен ли LDAP.

Реализация маршрутов — src/api/routers/auth_suite/auth_external_routes.py. Точные payloads и response models берите из OpenAPI развёрнутой версии.

Настройка OAuth

Текущий типизированный набор включает GitHub, Google, GitLab, Keycloak, SourceCraft и GitVerse. Провайдер работает, только если включён и получил обязательные данные клиента. Настройте:

  • client ID и secret через одобренные заказчиком secret references;
  • точный redirect URI для публичного origin развёртывания;
  • authorize, token и user-info endpoints, если нужны overrides;
  • least-privilege scopes только для identity;
  • TLS trust, proxy, timeout и outbound allowlist;
  • владельца account linking и deprovisioning.

Регистрируйте callback URI точно. Не используйте wildcard redirects, не публикуйте client secrets и не разрешайте произвольные callback destinations от вызывающей стороны.

Проверка OAuth

При старте создаётся одноразовый state. Callback должен использовать тот же state и redirect context до обмена authorization code.

Для каждого включённого провайдера:

  1. подтвердите его наличие в /api/v1/auth/oauth/providers;
  2. начните вход с origin развёрнутой системы;
  3. проверьте consent и scopes провайдера;
  4. завершите callback один раз и убедитесь, что replay state отклоняется;
  5. проверьте локального пользователя и least-privilege role;
  6. проверьте logout, session expiry, disablement и audit events;
  7. выполните negative test отключённого или неверно настроенного провайдера без раскрытия секретов.

Успех браузера недостаточен: проверьте итоговую authorization boundary CodeGraph.

Настройка LDAP

LDAP settings включают enabled state, server, port, TLS, base DN, user и group search bases, bind identity и secret, object classes, identity attributes, membership attribute и role mapping. Между trust boundaries используйте ldaps:// или другой защищённый transport заказчика.

Для работы authenticator нужен опциональный пакет ldap3. Если LDAP настроен, но ldap3 отсутствует, /api/v1/auth/ldap/status сообщает о деградации: система не должна изображать работоспособную directory authentication.

Bind identity должна иметь минимальные права. Не записывайте submitted passwords, bind secrets, raw access tokens и полные directory entries.

Mapping ролей и lifecycle

Group-to-role mapping сопоставляет группы каталога локальным ролям viewer, analyst, reviewer или admin. Неоднозначное членство в нескольких группах проверяйте явно; privilege selection не должен зависеть от случайного порядка ответа каталога.

Проверьте joiner, mover и leaver:

  • первый вход и создание локального пользователя;
  • смену имени или email без privilege escalation;
  • удаление из группы и снижение роли;
  • отключение provider или directory account;
  • существующие sessions и API keys после deprovisioning;
  • аварийный локальный admin-доступ по политике заказчика.

Контракт разрешений после входа описан в RBAC.

Ошибка и восстановление

Разделяйте provider unavailability, invalid state, code exchange failure, TLS и DNS failure, directory bind failure, user search failure, group lookup failure, missing dependency и local DB error. Сохраняйте безопасный request или correlation ID.

Не переходите молча с enterprise identity на anonymous или over-privileged local access. Если break-glass одобрен, ограничьте его по времени, выдайте отдельные credentials, аудитируйте и проведите ревью после восстановления.

Доказательства приёмки

Зафиксируйте identity провайдера или каталога, digest effective config без секретов, TLS boundary, positive и negative login, отклонение state replay, role mapping, deprovisioning, rate limiting, audit events, recovery и точную release revision. Повторяйте проверки после изменений маршрутов, провайдера, зависимости, роли или session policy.