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

Обзор единого входа (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:

  1. Перейдите в Account settings и в левом меню нажмите Single sign-on.
  2. Нажмите Edit в панели Single sign-on.
  3. Выберите подходящий Identity provider в выпадающем списке — поля Login URL slug и Identity provider values заполнятся для выбранного провайдера.
Пример значений identity provider для провайдера SAML 2.0Пример значений identity provider для провайдера SAML 2.0

Процесс SSO

На схеме ниже показан базовый процесс, с помощью которого пользователи создаются в dbt при входе через SSO.

Диаграмма SSOДиаграмма 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.
    Затем все эти группы (и только они) назначаются лицензии пользователя. На этом шаге также удаляются любые разрешения, которые пользователь не должен иметь в соответствии с текущими сопоставлениями SSO‑групп.
  • 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 с использованием пароля:

  1. Убедитесь, что у всех пользователей есть учетные записи в вашем провайдере идентификации и что им назначен доступ к dbt, чтобы они не потеряли доступ.
  2. Предупредите всех пользователей dbt, что они больше не смогут использовать пароль для входа, если только они уже не являются администраторами с паролем.
  3. Мы НЕ РЕКОМЕНДУЕМ повышать пользователей до администраторов только для сохранения входа по паролю, так как это снизит уровень безопасности вашей среды dbt.

Нашли ошибку?

0
Loading