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.
Для каждого включённого провайдера:
- подтвердите его наличие в
/api/v1/auth/oauth/providers; - начните вход с origin развёрнутой системы;
- проверьте consent и scopes провайдера;
- завершите callback один раз и убедитесь, что replay state отклоняется;
- проверьте локального пользователя и least-privilege role;
- проверьте logout, session expiry, disablement и audit events;
- выполните 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.