Обзор единого входа (SSO) EnterpriseEnterprise +
В этом обзоре объясняется, как пользователи создаются (provisioning) в dbt с использованием единого входа (Single Sign-On, SSO). dbt поддерживает JIT‑провижининг (Just-in-Time) и вход, инициированный провайдером идентификации (IdP). Подробнее о поддерживаемых вариантах можно узнать здесь.
Предварительные требования
- У вас должен быть тариф dbt Enterprise или Enterprise+. Чтобы узнать больше, заказать демо или подключиться, свяжитесь с нами.
Auth0 URI
URI, используемый для SSO‑подключений в мультитенантных инстансах dbt, будет отличаться в зависимости от хостинг‑региона dbt. Чтобы найти URI для вашего окружения в dbt:
- Перейдите в Account settings и в левом меню нажмите Single sign-on.
- Нажмите Edit в панели Single sign-on.
- Выберите подходящий Identity provider в выпадающем списке — поля Login URL slug и Identity provider values заполнятся для выбранного провайдера.
Процесс SSO
На схеме ниже показан базовый процесс, с помощью которого пользователи создаются в dbt при входе через SSO.
Пояснение к диаграмме
- Login Page: Пользователь открывает страницу входа dbt, инициируя процесс SSO.
- IdP-Initiated Login: Пользователь открывает страницу входа dbt внутри провайдера идентификации, выбирая приложение dbt. Это запускает процесс входа через IdP.
- IdP Login Page: Пользователю предлагается войти в провайдер идентификации. В результате приложение dbt получает доступ к данным его учетной записи.
- Login?: Пользователь может выбрать — продолжить или прервать процесс входа.
- Yes: Пользователь входит, предоставляет доступ приложению dbt и продолжает.
- No: Пользователь не входит и возвращается на страницу входа IdP.
- User Exists?: На этом шаге проверяется, существует ли пользователь в базе данных пользователей dbt.
- Yes: Если да, этап создания пользователя пропускается.
- No: Если нет, создается новая запись пользователя в базе данных dbt.
- Create dbt User: Создается новая запись пользователя в базе данных dbt. Эта запись содержит адрес электронной почты пользователя, имя и фамилию, а также любые атрибуты IdP (например, группы), переданные провайдером идентификации. dbt отправит письмо для подтверждения, и пользователь должен выполнить шаги, описанные в разделе User experience, чтобы использовать SSO в dbt.
- Attach Matching Accounts: dbt находит все аккаунты, настроенные в соответствии с конфигурацией SSO, с которой пользователь вошел, и создает запись лицензии пользователя, связывающую пользователя с аккаунтом. На этом шаге также удаляются любые лицензии, которые пользователю не должны быть выданы в соответствии с текущей конфигурацией SSO.
- Attach Matching Permissions (Groups): dbt проходит по группам в соответствующих аккаунтах и находит все группы, которые подпадают под одну из следующих категорий:
- имеют SSO‑группу сопоставления, назначенную пользователю;
- имеют включенную опцию Assign by Default.
- dbt Application: После выполнения этих шагов пользователь перенаправляется в приложение dbt и может начать использовать его в обычном режиме.
Принудительное использование SSO
- SSO Enforcement: Если в вашей организации включен SSO, dbt будет принудительно требовать вход только через SSO для всех пользователей, кроме администраторов. По умолчанию, если у Account Admin или Security Admin уже есть пароль, они могут продолжать входить с использованием пароля. Чтобы запретить администраторам вход по паролю, отключите опцию Allow password logins for account administrators в разделе Single sign-on настроек аккаунта вашей организации (Account settings).
- SSO Re-Authentication: dbt будет запрашивать повторную аутентификацию через вашего SSO‑провайдера каждые 24 часа для обеспечения высокого уровня безопасности.
Как должны входить неадминистративные пользователи?
Неадминистративные пользователи, которые сейчас входят с использованием пароля, больше не смогут этого делать. Они должны входить с помощью корпоративного URL входа dbt Enterprise или через провайдер идентификации (IdP), например Okta, Microsoft Entra ID (ранее Azure AD) и т.д.
Рекомендации по безопасности
Существует несколько сценариев, в которых может потребоваться вход с использованием пароля. Мы рекомендуем следующие лучшие практики безопасности для двух наиболее распространенных случаев:
- Онбординг партнеров и подрядчиков — Мы настоятельно рекомендуем добавлять партнеров и подрядчиков в ваш провайдер идентификации. Такие IdP, как Okta и Microsoft Entra ID, предлагают возможности, специально предназначенные для временных сотрудников. Мы рекомендуем обратиться к вашей IT‑команде, чтобы предоставить SSO‑лицензию для таких ситуаций. Использование IdP обеспечивает высокий уровень безопасности, снижает риск утечек и значительно повышает уровень защищенности вашей среды dbt.
- Недоступность провайдера идентификации — Администраторы аккаунта по‑прежнему смогут входить с использованием пароля, что позволит им взаимодействовать с вашим провайдером идентификации для устранения проблемы.
- Оффбординг администраторов — При выводе администраторов из системы необходимо отозвать доступ к dbt, удалив пользователя из вашей среды; в противном случае они смогут продолжать входить с использованием учетных данных (username/password).
Следующие шаги для неадминистративных пользователей, которые сейчас входят по паролю
Если у вас есть неадминистративные пользователи, которые сегодня входят в dbt с использованием пароля:
- Убедитесь, что у всех пользователей есть учетные записи в вашем провайдере идентификации и что им назначен доступ к dbt, чтобы они не потеряли доступ.
- Предупредите всех пользователей dbt, что они больше не смогут использовать пароль для входа, если только они уже не являются администраторами с паролем.
- Мы НЕ РЕКОМЕНДУЕМ повышать пользователей до администраторов только для сохранения входа по паролю, так как это снизит уровень безопасности вашей среды dbt.

