Повезивање са изворима података и потврда идентитета у њима

Повезивање и потврда идентитета са извором података се обавља одвојено од потврде идентитета са услугом 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.

  1. Power Apps услуге у позадини захтевају податке директно од услуге Dataverse.
  2. Dataverse враћа резултате упита назад на Power Apps услуге у позадини.

Повезивање са другим изворима података

Уопште, Power Platform услуге користе конекторе за рад са спољним изворима података који нису Dataverse. Следећи дијаграм илуструје типичну путању коју користи конектор за управљање Azure API-јем (APIM).

Дијаграм који приказује Power Platform бацк-енд услуге које раде са АПИ Хуб / АПИ Манагемент конектором да би дошли до екстерних конектора података.

  1. Услуга Power Platform шаље захтев за повезивање Power Apps добављачу ресурса (RP).

  2. Power Apps РП тражи од АПИ Хуб-а да створи везу и олакша размену токена за аутентификацију.

  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 Server, примењује се на све релационе базе података.

  • Last updated on