Подключение и аутентификация в источниках данных
Подключение и аутентификация в источнике данных выполняется отдельно от аутентификации в службе Power Platform.
Давайте сначала посмотрим, как служба Power Platform подключается к источникам данных. Службы Power Platform подключаются к внешним источникам данных различными способами, но общая схема одна и та же. Затем мы рассмотрим, как аутентифицируются подключения. Учетные данные аутентификации могут быть одинаковыми или разными, в зависимости от приложения и используемых им источников данных.
Подключение к Microsoft Dataverse
Приложения на основе холста и моделей Power Apps подключаются напрямую к Dataverse без необходимости использовать отдельный соединитель. (Приложения на основе холста хранят согласие на работу с другими средами в поставщике ресурсов Power Apps (RP).) Power Automate проходит аутентификацию с помощью концентратора API, но все взаимодействия с данными после этого осуществляются непосредственно в Dataverse. И Power Apps, и Power Automate поддерживают устаревшие соединители, которые получают доступ Dataverse с помощью соединителей (например, Dynamics 365 (устарело) и Microsoft Dataverse (прежних версий)).
Заметка
Создание приложений на основе холста с Начать с данных использует значок соединителя заполнителя для подключения к Dataverse. Тем не менее, нет никакого фактического соединителя. Дополнительная информация представлена в теме Подключение приложений на основе холста к Microsoft Dataverse.
На следующей диаграмме показано, как приложения на основе холста работают с Dataverse.
- Серверные службы Power Apps запрашивают данные из Dataverse напрямую.
- Dataverse возвращает результаты запроса обратно в серверные службы Power Apps.
Подключение к другим источникам данных
Службы Power Platform обычно используют соединители для работы с внешними источниками данных, которые не являются Dataverse. Следующая диаграмма иллюстрирует типичный путь с использованием соединителя управления API Azure (APIM).
Служба Power Platform отправляет запрос на соединение поставщику ресурсов Power Apps (RP).
Power Apps RP запрашивает в концентраторе API создание соединения и обеспечение обмена токенами проверки подлинности.
Служба Power Platform отправляет запрос данных в соединитель управления API.
Соединитель управления API отправляет запрос в службу согласия, чтобы получить разрешение на доступ к файлу источника данных.
Служба согласия возвращает учетные данные соединителю управления API.
Соединитель управления API отправляет учетные данные согласия в Power Apps RP. Учетные данные хранятся в RP, чтобы Power Apps не запрашивал согласие снова при следующем запросе данных.
Заметка
Согласие для одного подключения приложения не дает согласия для всех приложений. Каждое согласие на подключение приложения для каждого пользователя является отдельным. Например, когда вы предоставляете соединение для использования в потоке Power Automate, вы даете согласие на то, чтобы поток использовал это соединение в будущем. Вам не нужно повторно давать согласие на повторное использование этого подключения в этом потоке. Для соединения, предоставленного автором потока, это согласие двойное (соединение и поток). Для соединения, предоставляемого пользователем, вызывающим поток (например, из приложения на основе холста), это тройка согласия (подключение, поток и пользователь).
Соединитель управления API передает запрос данных внешнему соединителю.
Соединитель отправляет запрос в источник данных.
Источник данных возвращает запрошенные данные соединителю.
Соединитель передает данные обратно в серверный кластер Power Platform.
Аутентификация для источников данных
Пользователи аутентифицируются в службе Power Platform в первую очередь. Затем, по отдельности, пользователи проходят аутентификацию в источнике данных, используя учетные данные, требуемые соединителю. Служба учетных данных концерта тора API всегда хранит учетные данные и управляет ими.
Некоторые соединители поддерживают несколько методов аутентификации. Аутентификация в источнике данных относится только к этому экземпляру источника данных. Она основана на методе аутентификации, который создатель выбрал при создании соединения.
Существует два типа методов аутентификации в Power Apps: явная и скрытая.
- Явная аутентификация означает, что для доступа к источнику данных используются только учетные данные пользователя приложения.
- Неявная аутентификация означает, что при создании соединения используются учетные данные, использованные создателем приложения.
Мы рекомендуем по возможности использовать явную аутентификацию. Это более безопасно.
Даже в случае явной аутентификации важно помнить, что именно права пользователя на источник данных определяют, что пользователь может видеть и редактировать.
Например, предположим, что у вас есть список SharePoint, включающий столбцы Имя и Зарплата. Затем вы создаете приложение, которое предоставляет только столбец Name. Это означает, что пользователи имеют доступ только к столбцу Name в вашем приложении.
Однако предположим, что ваши пользователи имеют разрешения на список SharePoint, которые позволяют им просматривать и редактировать как столбец Имя, так и столбец Зарплата. Теперь предположим, что конкретный пользователь имеет права Power Apps Maker на этот список SharePoint. В этом случае ничто не мешает этому пользователю создать новое приложение, которое обращается к столбцу Зарплата. Разрешения, которые вы предоставляете через пользовательский интерфейс вашего приложения, не запрещают разрешения источника данных, которые есть у пользователя.
Подробнее о разнице между явными и неявными подключениями. Хотя статья относится к SQL Server, она применима ко всем реляционным базам данных.
Связанные статьи
Безопасность в Microsoft Power Platform
Аутентификация в службах Power Platform
Хранение данных в Power Platform
Вопросы и ответы по безопасности Power Platform