Свързване и удостоверяване към източници на данни

Свързването и удостоверяването към източник на данни се извършва отделно от удостоверяването към Power Platform услуга.

Нека първо да разгледаме как Power Platform услугите се свързват с източници на данни. Power Platform услугите се свързват с външни източници на данни по различни начини, но общият модел е същият. След това ще разгледаме как се удостоверяват връзките. Идентификационните данни за удостоверяване може да са еднакви или различни в зависимост от приложението и източниците на данни, които използва.

Свързване с/със Microsoft Dataverse

Power Apps canvas и управляваните от модели приложения се свързват директно към Dataverse без нужда от отделен конектор. (Приложенията за платно съхраняват съгласие за работа с други среди в Power Apps доставчика на ресурси (RP).) Power Automate удостоверява с помощта на API Hub, но всички взаимодействия с данни след това са директно към Dataverse. И Power Apps и Power Automate поддържат наследени конектори, които осъществяват достъп Dataverse с помощта на конектори (например Dynamics 365 (отхвърлен) и Microsoft Dataverse (наследство)).

Бележка

Създаването на приложения за платно с Стартиране от данни използва икона на конектор за контейнер за свързване към Dataverse. Въпреки това не е включен действителен конектор. За повече информация вижте Свързване на приложенията за платно с Microsoft Dataverse.

Следващата диаграма илюстрира как приложенията за платно работят с Dataverse.

1. Power Apps back-end услугите изискват данни директно от Dataverse.
2. Dataverse връща резултатите от заявката обратно към Power Apps бекенд услугите.

Свързване с други източници на данни

Като цяло Power Platform услугите използват конектори за работа с външни източници на данни, които не са Dataverse. Следната диаграма илюстрира типичен път, използващ Azure API Management (APIM) конектор.

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 Hub винаги съхранява и управлява идентификационни данни.

Някои съединители поддържат повече от един метод за удостоверяване. Удостоверяването на източник на данни е специфично за този източник на данни екземпляр. Базира се на метода за удостоверяване, който производителят е избрал при създаването на връзката.

Има два типа източник на данни методи за удостоверяване в Power Apps: явно и неявно.

• Изричното удостоверяване означава, че идентификационните данни на потребителя на приложението се използват за достъп до източник на данни.
• Неявно удостоверяване означава, че се използват идентификационните данни, предоставени от производителя на приложението при създаване на връзката.

Препоръчваме ви да използвате изрично удостоверяване, когато е възможно. По-сигурно е.

Дори в случай на изрично удостоверяване е важно да запомните, че правата на потребителя върху източник на данни определят какво потребителят може да вижда и редактира.

Да предположим например, че имате SharePoint списък, който включва колони "Име" и "Заплата ". След това създавате приложение, което показва само колоната Име . Това означава, че потребителите имат достъп само до колоната "Име" в приложението ви.

Да предположим обаче, че вашите потребители имат SharePoint разрешения за списък, които им позволяват да преглеждат и редактират колоните "Име" и "Заплата ". Сега да предположим, че конкретен потребител има Power Apps права на производител на този SharePoint списък. В този случай нищо не пречи на този потребител да създаде ново приложение, което има достъп до колоната " Заплата ". Разрешенията, които давате чрез потребителския интерфейс на приложението си, не отказват източник на данни разрешения, които потребителят има.

Научете повече за разликата между явни и скрити връзки. Въпреки че статията се отнася за SQL Server, тя се отнася за всички релационни бази данни.

Свързани статии

Защита в Microsoft Power Platform
Удостоверяване на услуги на Power Platform
Съхранение на данни в Power Platform
ЧЗВ относно защитата на Power Platform

Вижте също

• Свързване на приложения за платно с Microsoft Dataverse
• Разлика между явни и скрити връзки
• Референция на конекторите на Power Platform - Microsoft Dataverse