Connexion et authentification aux sources de données
La connexion et l’authentification à une source de données se font de manière distincte de l’authentification à un service Power Platform.
Voyons d’abord comment les services Power Platform se connectent aux sources de données. Les services Power Platform se connectent aux sources de données externes de différentes manières, mais le modèle général est le même. Ensuite, nous verrons comment les connexions sont authentifiées. Les identifiants d’authentification peuvent être identiques ou différents, selon l’application et les sources de données qu’elle utilise.
Connexion à Microsoft Dataverse
Les applications pilotées par modèle et canevas Power Apps se connectent directement à Dataverse sans avoir besoin d’un connecteur séparé. (Les applications canevas stockent le consentement à travailler avec d’autres environnements dans le fournisseur de ressources Power Apps.) Power Automate s’authentifie à l’aide d’un hub d’API, mais toutes les interactions de données ultérieures sont directes vers Dataverse. Power Apps et Power Automate prennent en charge les connecteurs hérités qui accèdent à Dataverse à l’aide de connecteurs (par exemple, Dynamics 365 (obsolète) et Microsoft Dataverse (hérité)).
Note
La création d’applications canevas avec Démarrer à partir de données utilise une icône pour se connecter à Dataverse. Cependant, il n’y a pas de connecteur réel impliqué. Pour plus d’informations, reportez-vous à la rubrique Connecter des applications de canevas à Microsoft Dataverse.
Le diagramme suivant illustre la manière dont les applications de canevas fonctionnent avec Dataverse.
- Les services principaux Power Apps demandent des données directement à partir de Dataverse.
- Dataverse renvoie les résultats de la requête aux services principaux Power Apps.
Connexion à d’autres sources de données
En général, les services Power Platform utilisent des connecteurs pour utiliser de manière générale des sources de données externes autres que Dataverse. Le schéma suivant illustre un cheminement typique utilisant un connecteur Azure API Management (APIM).
Le service Power Platform envoie une demande de connexion au fournisseur de ressources (RP) Power Apps.
Le fournisseur de ressources Power Apps demande au hub d’API de créer une connexion et de faciliter l’échange de jetons d’authentification.
Le service Power Platform envoie une demande de requête de données au connecteur API Management.
Le connecteur API Management envoie une requête au service de consentement pour obtenir l’autorisation d’accéder à la source de données.
Le service de consentement renvoie les informations d’identification au connecteur API Management.
Le connecteur API Management envoie les informations d’identification de consentement au RP Power Apps. Les informations d’identification sont stockées dans le RP afin que Power Apps ne demande plus de consentement la prochaine fois que des données sont demandées.
Note
Le consentement pour une connexion d’application n’accorde pas le consentement pour toutes les applications. Le consentement de connexion à chaque application par utilisateur est distinct. Par exemple, lorsque vous offrez une connexion à utiliser dans un flux Power Automate, vous consentez à ce que le flux utilise cette connexion à l’avenir. Vous n’avez pas besoin de donner à nouveau votre consentement pour réutiliser cette connexion dans ce flux. Pour une connexion fournie par un créateur de flux, le double consentement porte sur la connexion et le flux. Pour une connexion fournie par un utilisateur invoquant un flux (par exemple, à partir d’une application canevas), il s’agit d’un consentement triple : connexion, flux et utilisateur.
Le connecteur API Management transmet la requête de données au connecteur externe.
Le connecteur envoie la requête à la source de données.
La source de données renvoie les données demandées au connecteur.
Le connecteur retransmet les données au cluster principal Power Platform.
Authentification aux sources de données
Les utilisateurs s’authentifient au service Power Platform en premier lieu. Ensuite, séparément, les utilisateurs s’authentifient auprès d’une source de données à l’aide des informations d’identification requises par le connecteur. Le service d’informations d’identification du hub d’API stocke et gère toujours les informations d’identification.
Certains connecteurs prennent en charge plusieurs méthodes d’authentification. L’authentification auprès d’une source de données est spécifique à cette instance source de données. Elle est basée sur la méthode d’authentification choisie par le fabricant lors de la création de la connexion.
Il existe deux types de méthodes d’authentification aux sources de données dans Power Apps : explicite et implicite.
- L’authentification explicite signifie que les informations d’identification de l’utilisateur de l’application sont utilisées pour accéder à source de données.
- L’authentification implicite signifie que les informations d’identification fournies par le créateur de l’application lors de la création de la connexion sont utilisées.
Nous vous recommandons d’utiliser l’authentification explicite dans la mesure du possible. Elle est plus sécurisée.
Même dans le cas de l’authentification explicite, il est important de rappeler que ce sont les droits de l’utilisateur sur une source de données qui déterminent ce que l’utilisateur peut voir et modifier.
Par exemple, supposons que vous ayez une liste SharePoint qui comprend les colonnes Nom et Salaire. Vous créez ensuite une application qui expose uniquement la colonne Nom. Cela signifie que les utilisateurs ont accès uniquement à la colonne Nom de votre application.
Toutefois, supposons que vos utilisateurs disposent d’autorisations de liste SharePoint qui leur permettent de voir et de modifier à la fois les colonnes Nom et Salaire. Maintenant, supposons qu’un utilisateur spécifique dispose de droits Power Apps Maker pour cette liste SharePoint. Dans ce cas, rien n’empêche cet utilisateur de créer une nouvelle application qui accède à la colonne Salaire. Les autorisations que vous accordez via l’interface utilisateur de votre application n’annulent pas les autorisations de la source de données dont dispose l’utilisateur.
En savoir plus sur la différence entre les connexions explicites et implicites. Bien que l’article fasse référence à SQL Server, cela s’applique à toutes les bases de données relationnelles.
Articles associés
Sécurité dans Microsoft Power Platform
Authentification auprès des services Power Platform
Stockage de données dans Power Platform
Power Platform FAQ sur la sécurité