Корпоративная авторизация (SSO / LDAP)

DoQA поддерживает возможность входа в коробочную (on-premise) установку DOQA под корпоративной учётной записью сотрудника — через единый вход компании (SSO по OpenID Connect) или корпоративный каталог (LDAP / Active Directory), без отдельного пароля DOQA. Локальный вход по паролю продолжает работать.

Способы входа

Способ	Что это	Кто проверяет	Авто-создание пользователя
Локальный пароль	email + пароль DOQA	сама DOQA	нет (через приглашение)
LDAP / Active Directory	email + доменный пароль	ваш LDAP/AD сервер	да, опционально (JIT)
Корпоративный SSO (OIDC)	вход через ваш IdP (Keycloak, AD FS, Azure AD/Entra, Blitz, GitLab self-managed…)	ваш IdP (с редиректом)	да, опционально (JIT)

Способы сосуществуют: кнопка корпоративного входа показывается на экране логина рядом с формой email/пароль; форму можно скрыть строгим режимом (см. ниже).

Как это работает

Подключается один корпоративный SSO-провайдер. Настройка — через переменные окружения; секрет хранится только на сервере.
При первом входе пользователь может создаваться автоматически (JIT) — по белому списку доменов почты или открыто; по умолчанию выключено.
Если у пользователя уже есть учётная запись DoQA с тем же подтверждённым email — внешняя учётка к ней безопасно привязывается (новый пользователь не создаётся).
Новый пользователь всегда получает права на «Просмотр» и не занимает слот лиценизии; реальные права выдаёт администратор внутри DoQA.
Можно включить строгий режим (запрет входа по локальному паролю для SSO-управляемых) с аварийным доступом для администраторов.

Минимум для старта (SSO)

Чтобы кнопка корпоративного входа появилась и вход заработал, достаточно пяти переменных:

SSO_ENABLED=true
SSO_ISSUER=https://idp.company.ru/realms/company      # или алиас SSO_BASE_URL
SSO_CLIENT_ID=doqa
SSO_CLIENT_SECRET=super-secret-from-idp
SSO_REDIRECT=https://doqa.company.ru/api/auth/sso/callback

Остальное (scopes, надпись на кнопке, JIT, кэши) имеет рабочие значения по умолчанию.

Важно

SSO_ISSUER должен быть доступен из контейнера бэкенда (по нему идут discovery/token/JWKS) и одновременно совпадать с хостом, на который редиректит браузер. В Docker частая ошибка: бэкенд видит keycloak:8089, а браузер — localhost. Хост должен быть одинаков с обеих сторон.
SSO_REDIRECT должен совпадать символ-в-символ с Redirect URI, зарегистрированным в IdP, и быть адресом, который видит браузер.

Шаги подключения SSO (OIDC)

Требования

DoQA доступна по HTTPS на постоянном адресе.
IdP доступен по сети из коробки (исходящие запросы к IdP не заблокированы).
IdP поддерживает OIDC discovery ({issuer}/.well-known/openid-configuration) и подпись токена RS256.

Зарегистрировать DOQA как OIDC-клиент в IdP

Создайте «приложение»/«клиент» (confidential, authorization code flow) и получите client_id, client_secret, issuer. Разрешите scope openid email profile. Redirect URI пропишите точно в виде:

https://<ВАШ_АДРЕС_DOQA>/api/auth/sso/callback

Любое расхождение Redirect URI (протокол/домен/порт/путь/слеш) → IdP откажет в входе. Сверяйте посимвольно.

Памятки по популярным IdP:

Keycloak: Clients → Create → OpenID Connect; Client authentication = On (secret во вкладке Credentials); Valid redirect URIs = ваш callback; issuer = https://{keycloak}/realms/{realm}.
AD FS / Azure AD (Entra ID): App registration; Redirect URI (Web) = ваш callback; выдайте client secret; включите выдачу ID-токена; настройте claims email, name.
GitLab self-managed: Admin/Group/User → Applications; Redirect URI = ваш callback; scopes openid email profile; issuer = базовый URL GitLab (https://gitlab.company.ru).

Прописать переменные и проверить

Заполните данные SSO и перезапустите приложение. Затем:

Откройте страницу входа DoQA → должна появиться кнопка корпоративного входа.
Нажмите → редирект в IdP → авторизуйтесь → возврат в DoQA уже залогиненным.

Переменные окружения SSO (полный справочник)

Коннектор (обязательное)

Переменная	Обяз.	Дефолт	Что это / на что влияет
SSO_ENABLED	да	false	Главный выключатель. Кнопка появляется только при true и заданных SSO_CLIENT_ID + SSO_CLIENT_SECRET + SSO_ISSUER.
SSO_ISSUER (алиас SSO_BASE_URL)	да	—	Базовый URL IdP — по нему берётся discovery и endpoints. Без хвостового слэша и без /.well-known/.... Значение iss в токене сверяется с ним.
SSO_CLIENT_ID	да	—	Идентификатор клиента из IdP. Сверяется с aud в токене.
SSO_CLIENT_SECRET	да	—	Секрет клиента (обмен кода на токен). Хранится только в env, не в БД, не в логах, не на фронте.
SSO_REDIRECT	да	—	Полный URL callback …/api/auth/sso/callback. Должен совпадать с Redirect URI в IdP и быть виден браузеру.
SSO_SCOPES	нет	openid email profile	Запрашиваемые scope (через пробел/запятую). openid обязателен. Группы не запрашиваются и не используются.
SSO_LABEL	нет	Corporate SSO	Надпись/название провайдера на экране входа.
SSO_TYPE	нет	oidc	Тип коннектора; поддержан только oidc.

JIT — авто-создание пользователей

Переменная	Обяз.	Дефолт	Что это / на что влияет
SSO_JIT_ENABLED	нет	false	Главный выключатель авто-создания (для SSO и LDAP). При false войти могут только заранее заведённые/приглашённые пользователи (или связанные по подтверждённому email).
SSO_JIT_MODE	нет	domain_allowlist	Политика допуска (действует при SSO_JIT_ENABLED=true): domain_allowlist — создавать, если домен email в списке; open — создавать любого из IdP (только для доверенной сети).
SSO_JIT_ALLOWED_DOMAINS	при domain_allowlist	пусто	Белый список доменов email через запятую/пробел (company.ru,company.com). Пустой список = никто не создаётся (безопасный дефолт).

Строгий режим (enforce) и аварийный доступ

Переменная	Обяз.	Дефолт	Что это / на что влияет
SSO_ENFORCE	нет	false	При true локальный пароль-вход запрещён для SSO-управляемых: тех, чей домен email ∈ SSO_JIT_ALLOWED_DOMAINS, или у кого есть привязанная SSO-учётка. Проверка серверная. LDAP не затрагивается.
SSO_BREAKGLASS_EMAILS	по смыслу при enforce	пусто	Email через запятую/пробел, которым пароль-вход разрешён всегда (аварийный доступ). Это единственный break-glass — авто-исключений нет.

Тонкая настройка (обычно не трогают)

Переменная	Дефолт	Что это / на что влияет
SSO_DISCOVERY_CACHE_TTL	3600	Сколько секунд кэшировать OIDC discovery.
SSO_JWKS_CACHE_TTL	3600	TTL кэша публичных ключей (JWKS). Влияет на скорость подхвата ротации ключей IdP.
SSO_CLOCK_LEEWAY	60	Допуск рассинхрона часов (сек) при проверке exp/iat/nbf.
SSO_STATE_TTL	600	Сколько секунд живёт начатый вход (state/nonce/PKCE). Мало → пользователь «не успевает» в IdP.