Введение

  • 10 мин

Чтобы внедрить содержимое Power BI в приложение, необходимо разработать приложение для получения токена доступа. Тип потока проверки подлинности (и маркер доступа) зависит от сценария внедрения.

Примечание

Сведения о сценариях внедрения см. в модуле Выбор продукта встроенной аналитики Power BI.

При использовании любого из сценариев приложение должно получить токен Azure AD. Токен Azure AD содержит утверждения для идентификации предоставленных разрешений для REST API для Power BI. Срок действия обычно составляет один час. Действительный токен Azure AD должен присутствовать во всех операциях API.

Использование интерактивного потока проверки подлинности

Чтобы получить токен Azure AD для сценария Для организации, приложение использует интерактивный поток проверки подлинности. Интерактивный поток проверки подлинности означает, что Azure AD может предложить пользователю выполнить вход с помощью имени пользователя и пароля и (возможно) с помощью многофакторной проверки подлинности (MFA). Azure AD также может предложить пользователю предоставить дополнительное согласие на ресурсы (требуется при первом входе в приложение).

Примечание

Если приложение поддерживает единый вход (SSO), пользователям не нужно выполнять вход при каждом использовании. Процесс проверки подлинности кэширует учетные данные в файле cookie сеанса, когда пользователь проходит проверку подлинности в первый раз, и приложение может использовать эти кэшированные учетные данные до истечения срока их действия, т. е. через 90 дней по умолчанию.

После получения приложение должно кэшировать токен Azure AD. Затем приложение будет использовать его для внедрения содержимого Power BI, на работу с которым у пользователя есть разрешение.

В следующем видео показано использование интерактивного потока проверки подлинности.

Вы узнаете, как получить токены Azure AD, в 3-м уроке.

Использование неинтерактивного потока проверки подлинности

Чтобы получить токен Azure AD для сценария Для клиентов, приложение использует неинтерактивный поток проверки подлинности. Пользователям приложения не требуется иметь учетную запись Power BI, и даже если они это делают, эти учетные записи не используются. Выделенное удостоверение Azure AD, известное как удостоверение внедрения, выполняет проверку подлинности с помощью Azure AD. Внедренное удостоверение может быть субъектом-службой или главной учетной записью пользователя.

Неинтерактивный поток проверки подлинности также называется автоматической проверкой подлинности. Он пытается получить токен Azure таким образом, чтобы служба проверки подлинности не запрашивала у пользователя дополнительные сведения. После проверки подлинности пользователя в приложении (приложение может использовать любой выбранный метод проверки подлинности), оно использует удостоверение внедрения для получения токена Azure AD с помощью потока неинтерактивной проверки подлинности.

Когда приложение получает маркер Azure AD, оно кэширует его, а затем использует его для создания токена внедрения. Токен внедрения представляет факты о содержимом Power BI и способах доступа к нему.

В частности, токен внедрения описывает:

  • Утверждения к определенному содержимому Power BI.
  • Уровень доступа, заданный для просмотра, создания или изменения. (Уровни создания и изменения применяются только к отчетам Power BI.)
  • Время существования токена, определяющее, когда его срок действия истекает.
  • При необходимости утверждение к целевой рабочей области для сохранения новых отчетов.
  • При необходимости одно или несколько действующих удостоверений, чтобы служба Power BI могла применять разрешения на доступ к данным.

Примечание

Сведения о действующих удостоверениях см. в модуле Применение разрешений на доступ к данным для встроенной аналитики Power BI.

Просмотрите видео ниже, демонстрирующее использование неинтерактивного потока проверки подлинности.

Вы узнаете, как получить токены, в 3-м уроке.

Использование субъекта-службы

Приложение может использовать субъект-службу для получения токена Azure AD. Субъект-служба Azure — это приложение, используемое для удостоверений безопасности. Он определяет политику доступа и разрешения для приложения в клиенте Azure AD, включая основные функции, такие как проверка подлинности приложения во время входа и авторизация во время доступа к ресурсам. Субъект-служба может пройти проверку подлинности с помощью секрета приложения или сертификата. Мы рекомендуем защитить субъекты-службы с помощью сертификатов для рабочих приложений, а не секретных ключей, так как они более безопасны.

Когда удостоверение внедрения приложения является субъектом-службой, администратор клиента Power BI сначала должен:

  • разрешить использование субъектов-служб;
  • зарегистрировать группу безопасности, которая их содержит.

На следующем рисунке показаны параметры разработчика (находятся в параметрах клиента на портале администрирования), где администратор Power BI может разрешить субъектам-службам использовать API Power BI.

Снимок экрана: параметры разработчика с включенным использованием субъектов-служб.

Важно!

Если администратор разрешает использование субъекта-службы с Power BI, разрешения Azure AD приложения больше не вступают в силу. После этого администраторы будут управлять разрешениями приложения на портале администрирования Power BI.

В Power BI для внедрения содержимого рабочей области субъект-служба должна принадлежать администратору рабочей области или роли участника. Только новые рабочие области поддерживают назначения ролей субъекту-службе, а личные рабочие области не поддерживаются.

Примечание

В службу Power BI невозможно войти с помощью субъекта-службы.

Дополнительные сведения см. в разделе:

Использование главной учетной записи пользователя

Приложение может использовать главную учетную запись пользователя для получения токена AD. Главная учетная запись пользователя — это обычный пользователь Azure AD. В Power BI для внедрения содержимого рабочей области учетная запись должна принадлежать администратору рабочей области или роли участника. Она также должна иметь лицензию Power BI Pro или Power BI Premium на пользователя (PPU).

Примечание

Главную учетную запись пользователя нельзя использовать для внедрения отчетов с разбивкой на страницы.

Сравнение типов удостоверений внедрения

Мы рекомендуем использовать для рабочих приложений субъект-службу. Он обеспечивает наивысшую безопасность, и по этой причине это подход, рекомендуемый Azure AD. Кроме того, он лучше поддерживает автоматизацию и масштабирование, а также требует меньше затрат на управление. Однако для настройки и управления им требуются права администратора Power BI.

Вы можете использовать главную учетную запись пользователя для разработки или тестирования приложений. Ее легко настроить, и ее можно использовать для входа в службу Power BI, чтобы помочь устранить неполадки. Однако для нее требуется лицензия Power BI Pro или PPU. Кроме того, главная учетная запись не может требовать многофакторную проверку подлинности.

В сводной таблице ниже сравниваются два типа удостоверений внедрения.

Элемент Субъект-служба Главная учетная запись пользователя
Тип объекта Azure AD Субъект-служба Пользователь
Управление учетными данными Используйте секреты или сертификаты с периодической сменой Часто обновляйте пароли
Параметры клиента Power BI Администратор Power BI должен разрешить использование субъектов-служб; Рекомендуется, чтобы субъекты-службы принадлежали к выделенной группе безопасности Неприменимо
Использование REST API для Power BI Некоторые операции администрирования и потоков данных не поддерживаются; Вы можете включить проверку подлинности субъекта-службы для API администратора только для чтения. Поддерживаются все операции
Вход в службу Power BI Не поддерживается Поддерживается
Лицензирование Не требуется Power BI Pro или PPU
Рекомендации Azure AD Рекомендуется (особенно для рабочих приложений) Не рекомендуется (но может подходить для разработки или тестирования приложений)
Дополнительные сведения Не может требовать многофакторную проверку подлинности; нельзя внедрять отчеты с разбивкой на страницы