Поділитися через

Підключення до джерел даних і автентифікація в них

  • Стаття

Підключення та автентифікація до джерела даних здійснюється окремо від автентифікації у службі 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. Однак жоден фактичний з'єднувач не задіюється. Додаткові відомості див. у розділі Підключення компонованих програм Dynamics 365 до Microsoft Dataverse.

На схемі нижче декларується спосіб роботи компонованих програм із Dataverse.

Діаграма, яка показує прямий зв’язок між Power Apps внутрішнім кластером та Dataverse.

  1. Серверні служби Power Apps запитують дані безпосередньо з Dataverse.
  2. Dataverse повертає результати запиту назад до серверних служб Power Apps.

Підключення до інших джерел даних

В цілому, служби Power Platform використовують з'єднувачі для роботи з зовнішніми джерелами даних, які не належать до Dataverse. На наведеній нижче схемі зображено типовий шлях, що використовує З'єднувач для керування програмами Azure API (APIM).

Діаграма, на якій показано, як Power Platform внутрішні служби працюють із конектором API Hub/API Management для доступу до зовнішніх з’єднувачів даних.

  1. Служба Power Platform надсилає запит підключення до постачальника ресурсів Power Apps (RP).

  2. Power Apps RP просить API Hub створити з’єднання та полегшити обмін токенами автентифікації.

  3. Служба Power Platform надсилає запит даних до з’єднувача керування API.

  4. З’єднувач керування API надсилає запит до служби отримання згоди, щоб отримати дозвіл на доступ до джерела даних.

  5. Служба надання згоди повертає облікові дані в з’єднувач керування API.

  6. З’єднувач керування API надсилає облікові дані для отримання згоди до Power Apps RP. Облікові дані зберігаються в RP, щоб Power Apps не запитував згоду під час наступного запиту даних.

    Нотатка

    Згода на одне підключення програми не дає згоди на всі програми. Згода на підключення кожної програми на одного користувача окрема. Наприклад, якщо ви надаєте з’єднання для використання в циклі Power Automate, ви погоджуєтеся на використання цього з’єднання. Більше не потрібно погоджуватись на повторне використання цього з’єднання в цьому циклі. Для з’єднання, передбаченого автором циклу, згода подвійна (з’єднання та цикл). Для з’єднання, передбаченого користувачем, який викликає потік (наприклад, з компонованої програми), згода потрійна (з’єднання, цикл і користувач).

  7. З’єднувач керування API передає запит даних до зовнішнього з’єднувача.

  8. З’єднувач надсилає запит до джерела даних.

  9. В джерело даних повертаються запитані дані до з’єднувача.

  10. З’єднувач знову передає дані до серверного кластера Power Platform.

Автентифікація у джерелі даних

Користувачі спочатку автентифікуються у службі Power Platform. Потім, окремо, користувачі проходять автентифікацію у джерелі даних із використанням облікових даних, необхідних для з’єднувача. Служба облікових даних центра API завжди зберігає облікові дані й керує ними.

Деякі з’єднувачі підтримують кілька методів автентифікації. Автентифікація в джерелі даних відрізняється залежно від екземпляра джерела даних. Це залежить від способу автентифікації, вибраного розробником під час створення з’єднання.

Існує два типи способів автентифікації джерела даних у Power Apps: явний і неявний.

  • Явна автентифікація означає, що облікові дані користувача програми використовуються для доступу до джерело даних.
  • Неявна автентифікація означає, що використовуються облікові дані, які виробник програми надав під час створення з’єднання.

Рекомендовано явно використовувати автентифікацію в разі можливості. Це безпечніше.

Навіть у разі явної автентифікації важливо пам’ятати, що саме права користувача на джерело даних визначає, що користувач може бачити та редагувати.

Наприклад, у вас є список SharePoint , який містить стовпці «Ім’я» та «Зарплата ». Потім ви створюєте програму, яка відображає лише стовпець «Ім’я ». Це означає, що користувачі мають доступ лише до стовпця "Ім’я " у вашому додатку.

Однак припустімо, що ваші користувачі мають SharePoint дозволи на список, які дозволяють їм переглядати та редагувати стовпці «Ім’я» та «Зарплата ». Тепер припустимо, що конкретний користувач має Power Apps права виробника на цей SharePoint список. У цьому випадку ніщо не заважає цьому користувачеві створити нову програму, яка отримує доступ до стовпця «Зарплата ». Дозволи, які ви надаєте в інтерфейсі користувача додатка, не скасовують дозволи джерело даних, які має користувач.

Дізнайтеся більше про різницю між явними та неявними з'єднаннями. Хоча стаття стосується серверу SQL, вона застосовується до всіх реляційних баз даних.

Безпека в Microsoft Power Platform
Автентифікація в Power Platform службах
Зберігання даних в Power Platform
Power Platform Поширені запитання про безпеку

Див. також