Перейти к содержимому
GitRiverGitRiver
EN
Навигация

Аутентификация

Настройка способов входа: OAuth2, SAML, SCIM, LDAP, 2FA, токены доступа

GitRiver поддерживает несколько способов аутентификации: от простого логина/пароля до корпоративного единого входа через SAML. В этом разделе - как настроить каждый из них.

Логин и пароль

Базовый способ. Работает из коробки, настройка не требуется. Пользователи регистрируются сами (если не отключено) или создаются администратором.

Чтобы отключить открытую регистрацию: Администрирование -> Система -> снять флажок «Разрешить регистрацию».

Двухфакторная аутентификация (2FA)

2FA добавляет второй фактор при входе - код из приложения. Даже если пароль скомпрометирован, без кода войти нельзя.

Включение для пользователя

  1. Откройте Настройки (аватар -> шестерёнка) -> Безопасность
  2. Нажмите «Включить 2FA»
  3. Отсканируйте QR-код приложением (Google Authenticator, Authy, FreeOTP)
  4. Введите 6-значный код из приложения для подтверждения
  5. Сохраните 10 резервных кодов - каждый используется один раз, если телефон недоступен

Как работает вход с 2FA

  1. Пользователь вводит логин и пароль
  2. Если 2FA включена - появляется поле для кода
  3. Пользователь вводит код из приложения (или резервный код)
  4. Вход выполнен

Отключение

Настройки -> Безопасность -> «Отключить 2FA» (требуется пароль).

OAuth2 провайдеры

OAuth2 позволяет пользователям входить через внешние аккаунты: GitHub, GitLab, Google или любой OAuth2/OIDC-совместимый провайдер.

Когда нужно

  • Пользователи уже имеют аккаунты в GitHub/Google
  • Не хочется управлять отдельными паролями
  • Нужна автоматическая регистрация при первом входе

Настройка

  1. Откройте Администрирование -> OAuth
  2. Нажмите «Добавить провайдер»
  3. Выберите тип: GitHub, GitLab, Google или Generic (для произвольного OIDC)
  4. Укажите:
    • Client ID и Client Secret - получите в настройках OAuth-приложения у провайдера
    • Scopes (опционально) - разрешения (по умолчанию стандартные для провайдера)
  5. Сохраните

На странице входа появится кнопка «Войти через [провайдер]».

Для GitHub: создайте OAuth App в Settings -> Developer settings -> OAuth Apps. Redirect URL: https://git.example.com/api/v1/auth/oauth/{provider_id}/callback.

SAML 2.0 (Max)

SAML обеспечивает корпоративный единый вход через Identity Provider: Okta, Azure AD, Keycloak, OneLogin и другие.

Когда нужно

  • В компании есть централизованный IdP
  • Нужен единый вход (SSO) - один аккаунт для всех сервисов
  • Требуется автоматическая синхронизация групп из IdP

Настройка в GitRiver

  1. Откройте Администрирование -> SAML SSO
  2. Нажмите «Добавить провайдер»
  3. Заполните:
    • Название - как кнопка будет называться на странице входа
    • Entity ID провайдера (IdP) - идентификатор вашего IdP
    • URL для входа (SSO URL) - куда перенаправлять пользователя для входа
    • URL для выхода (SLO URL) - для единого выхода (опционально)
    • Сертификат IdP - публичный сертификат для проверки подписей
  4. Настройте маппинг атрибутов:
    • Имя пользователя, email, отображаемое имя, группы
  5. Опционально: автоматическая регистрация и синхронизация групп
  6. Сохраните

Настройка в IdP

На странице созданного провайдера вы найдёте ссылку на SP metadata (XML). Скачайте его и загрузите в ваш IdP, или укажите вручную:

  • ACS URL - https://git.example.com/api/v1/auth/saml/{id}/acs
  • Entity ID - из SP metadata

SCIM 2.0 (Max)

SCIM автоматически синхронизирует пользователей и группы из IdP (Okta, Azure AD). При добавлении сотрудника в IdP - он автоматически появляется в GitRiver. При удалении - деактивируется.

Настройка

  1. Откройте Администрирование -> SCIM
  2. Нажмите «Создать токен»
  3. Сохраните токен - он показывается только один раз
  4. В настройках IdP (Okta, Azure AD):
    • SCIM Base URL: https://git.example.com/scim/v2/
    • Bearer Token: токен из шага 3
  5. Включите провижининг в IdP

LDAP (Max)

LDAP позволяет входить с учётными данными из корпоративного каталога (Active Directory, OpenLDAP). Пользователю не нужно создавать отдельный аккаунт в GitRiver.

Настройка через интерфейс

  1. Откройте Администрирование -> LDAP
  2. Нажмите «Настроить» (или «Изменить» если уже настроено)
  3. Заполните:
    • URL сервера - ldap://host:389 или ldaps://host:636 (с TLS)
    • Bind DN - DN сервисного аккаунта для поиска (опционально)
    • Пароль - пароль сервисного аккаунта
    • База поиска - где искать пользователей (ou=users,dc=example,dc=com)
    • Фильтр пользователей - как находить пользователя ((uid={login}) - {login} заменится на введённый логин)
    • Атрибут email - обычно mail
  4. Нажмите «Тест подключения» - GitRiver попробует подключиться и найти пользователей
  5. Если тест успешен - «Сохранить»

Как работает вход

  1. Пользователь вводит логин и пароль на странице входа GitRiver
  2. GitRiver ищет пользователя в LDAP по фильтру
  3. Пытается выполнить bind с найденным DN и введённым паролем
  4. Если успех - создаёт (или обновляет) локальный аккаунт и авторизует

Локальные пароли работают как запасной вариант: если LDAP недоступен, пользователь может войти по локальному паролю (если он был установлен).

Настройка через конфиг

Альтернативно, LDAP настраивается в gitriver.toml - см. раздел Конфигурация -> LDAP.

Корпоративный вход и места Max

SAML, SCIM и LDAP - возможности редакции Max, в Community их нет. Отсюда два правила, и оба стоит знать до покупки.

Входящему только по домену нужно место. Учётная запись, у которой нет ни пароля, ни привязанного входа через OAuth, то есть входящая только через SAML или LDAP (так обычно выглядят записи, заведённые через SCIM или при первом входе из каталога), работает лишь с назначенным местом Max. Без места вход выполняется, но работать нельзя - ни в интерфейсе, ни через API, ни по git, - и GitRiver сообщает, что место назначает администратор. Место назначается на странице пользователя (Администрирование -> Пользователи), само при первом входе оно не выдаётся. Учётная запись, у которой есть пароль или привязанный вход через OAuth, без места работает как в Community - каким бы способом человек ни вошёл в этот раз.

По окончании льготного срока корпоративный вход закрывается. Пока идёт льготный срок, всё работает, а предупреждение с датой видит каждый вошедший, не только администратор. Когда срок вышел, вход через SAML и LDAP перестаёт пускать кого бы то ни было. Вход паролем и через OAuth продолжает работать, данные остаются на месте, установка работает как Community. Администратор может задать пароль любой учётной записи на её странице, и GitRiver не даёт убрать последнего администратора, входящего паролем, - поэтому перевести людей на пароли и загрузить новую лицензию всегда есть кому.

Длина льготного срока записана в лицензии и зависит от срока подписки - см. льготный срок после истечения и цены.

GitRiver как поставщик OAuth2/OIDC

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

  • GET /.well-known/openid-configuration - конфигурация;
  • GET /.well-known/jwks.json - публичные ключи.

Подпись id_token - RS256. Ключ заводится сам при первом запуске: приватная часть хранится в базе зашифрованной, публичная отдаётся в JWKS. Отдельной настройки не требует и попадает в резервную копию базы вместе с остальными данными.

Отсюда два правила эксплуатации:

  • jwt_secret менять нельзя, не потеряв ключ подписи. Он расшифровывается выведенным из него ключом; после смены секрета старый ключ подписи прочитать нельзя, установка заведёт новый, а выданные ранее id_token перестанут проверяться. Получатели переживут это как разовый повторный вход.
  • Восстановление базы из копии восстанавливает и ключ, поэтому получателям не нужно перечитывать JWKS после восстановления.

Получатель обязан взять ключи по jwks_uri и выбрать тот, чей kid указан в заголовке токена (а не запоминать единственный ключ навсегда), проверить подпись, iss, aud и exp, а затем сверить nonce с отправленным в запросе авторизации. id_token, выданный при обновлении токена, nonce не содержит: пользователь в этом обмене не участвует.

Токены доступа

Персональные токены (PAT)

Для автоматизации: скрипты, CI/CD внешних систем, docker login. Подробнее - в разделе Первые шаги -> Токены доступа.

Токены развёртывания

Привязаны к конкретному репозиторию. Используются для Docker pull из production-серверов или CI/CD внешних систем.

  1. Откройте репозиторий -> Настройки -> Токены развёртывания
  2. Нажмите «Создать»
  3. Укажите имя, имя пользователя для docker login, скоупы и срок действия

Управление сессиями

Пользователь может видеть свои активные сессии и завершить любую из них.

Настройки -> Безопасность -> Активные сессии -> кнопка «Завершить» рядом с сессией.

Администратор может завершить сессию любого пользователя через управление пользователями.