Configuration de la connexion Dataverse

Votre portail communique avec Dataverse en tant qu’application à part entière, et non en tant que visiteur qui le consulte. Cela comporte deux éléments : une inscription dans l’identifiant Microsoft Entra qui possède les identifiants, et un utilisateur applicatif dans votre environnement Dataverse qui donne à ces identifiants une identité et un rôle de sécurité. Cette page parcourt les deux, ainsi que l’accès dont le portail a réellement besoin.

Ce n’est pas l’application de connexion

Cette inscription est l’identité de service propre au portail — elle lit et écrit les données au nom du portail, et ses identifiants vont sous D365:ClientId / D365:ClientSecret. Un second enregistrement séparé gère la connexion des utilisateurs chez Microsoft. Gardez-les séparés : celui-ci ne nécessite ni URI de redirection ni permissions déléguées, mais il détient bien plus de pouvoir dans votre environnement. Voir Configuration de connexion Entra ID

1. Enregistrer la demande

Créez l’enregistrement dans le centre d’administration Microsoft Entra, dans le locataire qui possède votre environnement Dataverse.

  1. Parcourez Entrée ID > Inscriptions à l’application et sélectionnez Nouvelle inscription.
  2. Saisissez un Nom qui identifie le portail et l’environnement, par Contoso Portal — Dataverse (Production)exemple. Personne ne voit cela sur un écran de consentement, donc privilégiez la clarté pour ceux qui l’auditeront plus tard.
  3. Dans la section Types de comptes supportés, choisissez Tenant unique uniquement. Cette identité ne quitte jamais votre organisation.
  4. Laissez l’URI de redirection vide. Aucun utilisateur n’est jamais redirigé ici — le portail s’authentifie avec le flux d’identifiants client, machine à machine, sans navigateur impliqué.
  5. Sélectionnez Inscrire.
  6. Sur la page Aperçu , copiez l’ID de l’application (client). Cette valeur devient D365:ClientId, et vous en avez besoin à nouveau à l’étape 4 pour créer l’utilisateur de l’application.

2. Créer un secret client

Le secret est la seule accréditation du portail, alors considérez-le comme la clé des données de votre environnement.

  1. Ouvrez Certificats & secrets sous Gérer et sélectionnez l’onglet Secrets du client.
  2. Sélectionnez Nouveau secret client, décrivez-le par environnement (par exemple portal-production), puis choisissez une date d’expiration.
  3. Copiez immédiatement la colonne Valeur — pas l’ID Secret. Elle n’est affichée qu’une seule fois, et elle devient D365:ClientSecret.

Important

Lorsque le secret expire, le portail cesse complètement d’atteindre Dataverse — pas seulement pour une fonctionnalité, mais pour chaque requête — alors inscrivez la date d’expiration quelque part où vous la verrez. Pour la production, une certification de certificat évite la falaise d’expiration et AuthenticationType.Certificate en accepte une à la place du secret.

3. Autorisations API : Aucune requise

Cette étape est volontairement vide, ce qui surprend les gens. Beaucoup d’anciennes directives vous conseillent d’ajouter le CRM Dynamics → user_impersonation autorisation déléguée. Cette autorisation concerne les applications agissant au nom d’un utilisateur connecté. Le portail ne fait pas cela — il s’authentifie sous son propre nom, et son accès provient entièrement de l’utilisateur Dataverse que vous créez à l’étape suivante.

Note

Les directives serveur à serveur de Microsoft disent la même chose : lorsque vous vous connectez en tant qu’application, vous n’accordez pas Access Dynamics 365 en tant qu’utilisateurs de l’organisation, car l’application est liée à un compte utilisateur spécifique à la place. L’ajouter ne casse rien, mais cela accorde une fonctionnalité que le portail n’exerce jamais — laissez-la désactivée.

4. Créer l’utilisateur de l’application dans Dataverse

L’enregistrement de l’application seul ne peut pas toucher aux données. Dataverse a besoin d’un enregistrement utilisateur lié à celle-ci, ce qui transforme l’identifiant client en une identité reconnue par votre environnement.

  1. Connectez-vous au centre d’administration de Power Platform.
  2. Sélectionnez Gérer dans le panneau de navigation, puis Environnements, puis votre environnement.
  3. Sélectionnez Paramètres > Utilisateurs + permissions > Utilisateurs de l’application.
  4. Sélectionner + Nouvel utilisateur de l’application.
  5. Sélectionnez + Ajouter une application et trouvez votre inscription par nom ou par identifiant client à l’étape 1, puis sélectionnez Ajouter. Seules les inscriptions à l’application Entra apparaissent dans cette liste — les applications d’entreprise ne le font pas.
  6. Choisissez une unité métier. L’unité métier racine est la réponse habituelle ; une unité enfant réduit ce que le portail peut atteindre avant même que les rôles de sécurité ne s’appliquent.
  7. Sélectionnez l’icône d’édition à côté de rôles Sécurité et attribuez les rôles dont le portail a besoin — l’étape suivante explique lesquelles, et pourquoi il y en a généralement plusieurs.
  8. Sélectionne Créer.

Conseil

Un utilisateur d’application ne consomme aucune licence payante, et vous ne pouvez en avoir qu’une par enregistrement d’une application Entra par environnement. Utilisez une inscription séparée pour chaque environnement afin que la révocation de l’accès au développement n’affecte jamais la production.

5. Confier à l’utilisateur de l’application un rôle de sécurité

L’utilisateur de l’application ne peut rien faire tant qu’il n’occupe pas un rôle de sécurité. Il existe deux voies, et celle qui est correcte dépend d’une seule question : cela vous dérangerait-il que les identifiants du portail atteignent les données que le portail lui-même n’affiche jamais ?

La solution rapide : administrateur système

Assigner un administrateur système fonctionne, et là où l’environnement ne contient rien que vous refuseriez de dévoiler — une démo, un prototype, un bac à sable dont les données sont déjà publiques — c’est un choix raisonnable plutôt qu’une erreur. Faites-le simplement en connaissance de cause. Le portail est orienté vers Internet, et cette certification détermine jusqu’où va un attaquant si le secret fuit. Administrateur système signifie chaque table de l’environnement, y compris toutes celles que le portail n’a jamais été conçu pour afficher.

La voie à portée : notre rôle, plus un de vos propres rôles

Partout où se trouvent de vraies données, attribuez deux rôles. Les rôles de sécurité sont additifs, donc l’utilisateur de l’application finit par avoir l’union des deux — et les garder séparés vous permet de revoir vos propres subventions sans relire les nôtres.

  1. Assigner Power Portals Pro Application User, qui est livré dans la solution gérée. Il accorde exactement ce dont le framework a besoin pour fonctionner, et rien d’autre. Ajoutez ensuite l’utilisateur de l’application à la colonne profil de sécurité du même nom, qui est incluse : un rôle de sécurité ne peut jamais accorder une colonne sécurisée, et Power Pages sécurise deux colonnes de contact que le framework écrit comme lui-même, adx_identity_logonenabled et adx_identity_passwordhash. Sans le profil, les utilisateurs existants se connectent normalement et la première inscription échoue avec ne disposent pas des autorisations de création vers un champ sécurisé Connexion Activée. Faites de même pour chaque utilisateur d’application auquel le portail se connecte, y compris une identité gérée dans une application déployée.
  2. Créez un second rôle personnalisé pour vos propres tables. Dataverse vous permettrait de les ajouter au rôle de livraison à la place, mais de les garder séparés : le rôle de livraison est le nôtre, une mise à jour de solution peut le réappliquer, et les extensions intégrées ne sont plus susceptibles d’être examinées sans lire les nôtres en même temps. Avec le serveur MCP, il create_security_role le crée et assign_application_user_role le donne à l’utilisateur de l’application.
  3. Ajoutez vos tables à ce rôle. Si vous utilisez le serveur MCP, cela ne nécessite aucun passage par le formulaire de rôle de sécurité — describe_role_table_privileges cela montre ce qu’un rôle accorde actuellement sur une table et à quelle profondeur, et add_table_privileges_to_role accorde ce qui manque. L’attribution ne retire jamais rien : remove_table_privileges_from_role cela fait cela, en supprimant des privilèges ou en diminuant la profondeur, et delete_security_role supprime un rôle dès que personne ne le détient. Aucun d’eux ne touche à un rôle géré, y compris celui livré, donc les subventions tombent toujours dans le vôtre.

Important

Lors de l’autorisation améliorée, assignez Power Portals Pro Application User - Enhanced Authorization à la place. Il est livré dans la solution Power Portals Pro Enhanced Authorization et constitue un surensemble du rôle ci-dessus — tous les privilèges accordés, à la même profondeur, plus ceux pour la lecture des rôles web et la maintenance de la configuration des rôles Web. Il remplace le rôle envoyé au lieu de le rejoindre, donc attribuer les deux est inoffensif mais inutile. Sans cela, le portail ne peut pas lire les rôles web : les nouveaux utilisateurs n’en reçoivent aucun, et le portail ne leur montre rien sans signaler d’erreur. Le profil de sécurité de la colonne reste nécessaire de toute façon — aucun rôle de sécurité, aussi large soit-il, ne peut accorder une colonne sécurisée.

Ce que le rôle d’envoi prévoit déjà

Power Portals Pro Application User est dérivé des appels que le framework effectue en tant que lui-même, ce qui suit ce dont le framework a réellement besoin plutôt que ce qui semblait prudent à l’époque :

Ce que fait le portail Accéder aux besoins du poste
Inscriptions et connexions des utilisateurs du portail Créer, lire et écrire sur contact, et créer, lire, écrire et supprimer sur adx_externalidentity, qui stocke le lien entre un utilisateur du portail et une connexion externe.
Lie les grilles aux vues Dataverse et forme les valeurs Lisez la suite savedquery, et lisez organizationencore, usersettings et transactioncurrency donc les dates, les chiffres et le format de la monnaie correctement.
Envoie un email de confirmation et de réinitialisation du mot de passe Créer, lire et écrire sur email, et lire sur l’adresse queue de l’expéditeur configurée vers la résolution de votre adresse d’expéditeur configurée.
Rôles du portail Créer, lire, écrire et supprimer sur ppp_portalrole et ppp_portalroleconfiguration, et Ajouter/Ajouter sur contact afin que les rôles puissent être attribués. Le portail lui-même ne les lit qu’à l’exécution ; les privilèges d’écriture sont là pour que RoleManager<PortalRole> cela fonctionne pour les hôtes qui gèrent les rôles dans le code, et ainsi les outils de rôle du portail du serveur MCP fonctionnent dans un projet qui se connecte en tant qu’utilisateur de l’application.
Valide la licence du site web Permission d’exécuter l’action ppp_ProWebsiteLicenseCheck , et Lire la suite ppp_powerportalsprowebsite — l’action s’exécute dans le contexte de l’appelant, donc elle lit les enregistrements du site web comme utilisateur de l’application. L’absence de l’un ou l’autre fait que chaque terminaison licencié restitue 402, qui se lit comme une licence expirée plutôt qu’un privilège manquant.
Sécurité native Dataverse Créer, lire et écrire sur systemuser, lire la suite businessunit et role, créer et lire sur powerpagesusermapping, lire la suite powerpagesite, et la loi au nom d’un autre privilège d’utilisateur sur laquelle repose l’usurpation d’identité.

Ce que cela ne couvre délibérément pas, ce sont vos propres tables — aucun rôle que nous attribuons ne peut savoir ce qu’elles sont, ce à quoi sert le rôle personnalisé ci-dessus. Attendez-vous à créer des tableaux exposés par votre portail, à l’ampleur que vous souhaitez atteindre par les visiteurs. C’est l’essentiel du travail, et c’est entièrement spécifique à votre application.

Important

L’usurpation d’identité réduit la portée. Elle ne l’élargit jamais. Sous la sécurité Dataverse-native, le portail tamponne chaque requête avec l’identité du visiteur connecté, et Dataverse applique l’intersection des privilèges de ce visiteur et de ceux de l’utilisateur de l’application — une opération n’est autorisée que si les deux en détiennent les droits. Ainsi, le rôle de l’utilisateur de l’application est un plafond à ce que tout visiteur peut faire. Un visiteur dont le rôle accorde la lecture sur une table ne lit toujours rien si l’utilisateur de l’application en manque, et ajouter une table à votre rôle personnalisé n’accorde jamais plus à un visiteur que son propre rôle déjà autorisé.

6. Stocker les paramètres de connexion

Le portail les lit depuis la configuration sous la D365 section. Gardez-les dans les secrets utilisateur pendant le développement afin qu’elles n’atteignent jamais le contrôle de version :

EmailSenderEmailAddress est l’adresse depuis laquelle l’email sortant du portail est envoyé. Il doit correspondre à un queue ou à un activé systemuser dans l’environnement — une file d’attente est le choix habituel, car elle ne lie pas le courrier du portail à une personne qui pourrait partir plus tard.

Création de la file d’attente de l’expéditeur

Commencez par Exchange Online : créer une boîte aux lettres partagée pour l’adresse d’où le courrier doit provenir — no-reply@yourcompany.com est le choix habituel. Une boîte aux lettres partagée n’a pas besoin de licence. Ensuite, dans le portail créateur, Paramètres avancés → Gestion des affaires → files d’attente → Nouveau, donnez cette adresse à la file d’attente, et enregistrez ; Dataverse crée un enregistrement de boîte mail pour celle-ci dans le profil Exchange Online de l’environnement. Une file d’attente est la bonne solution pour un expéditeur sans réponse, et elle vaut mieux que de pointer le portail vers le compte d’un collègue — dont le nom figurerait autrement sur chaque message automatisé envoyé par le portail, et dont le départ empêcherait complètement son envoi.

Important

La boîte aux lettres doit toujours être approuvée et activée. Ouvrez l’enregistrement de boîte aux lettres de la file d’attente et exécutez Approuver l’email — ce que seuls un administrateur global Office 365 ou un administrateur Exchange peut faire — puis Tester et activer la boîte aux lettres. Tant que cela n’a pas été passé, Dataverse accepte tout ce que le portail envoie et ne livre rien de tout cela. Aucune erreur n’arrive au portail, donc cela ressemble exactement à un e-mail fonctionnel jusqu’à ce que quelqu’un signale ne jamais avoir reçu de message de réinitialisation du mot de passe. Le serveur create_email_queue MCP gère la file d’attente, l’approbation et le test en un seul appel, et check_email_sender explique un expéditeur qui ne livre pas.

Conseil

Dans les environnements hébergés, fournir les mêmes clés que les variables d’environnement ou depuis un magasin secret, en utilisant un double soulignement à la place du deux-points — D365__ClientId, D365__Secret — car le séparateur des deux-points n’est pas portable entre plateformes.

Conseil

Une fois déployé sur Azure, vous pouvez supprimer ClientSecret complètement. Réglez D365:ManagedIdentityId sur l’identifiant client d’une identité managée attribuée par l’utilisateur et le portail s’authentifie sous cet identité — pas de secret, donc rien à expirer. Il a besoin de son propre utilisateur applicatif, créé à partir de cet identifiant client exactement comme à l’étape 4. Pour un environnement dans un autre locataire, il faut aussi définir D365:TenantId et l’identité devient l’identifiant de l’enregistrement de l’application à D365:ClientId la place. Voir le déploiement Azure.

7. Câbler la connexion

Le projet serveur se configure ConnectionOptions lors de l’enregistrement du framework :

Le modèle de projet écrit cela pour vous, donc dans un projet généré, il n’y a rien à ajouter ici — fournissez les trois valeurs de configuration et la connexion fonctionne. Ouvrez le portail et parcourez n’importe quelle page appuyée par les données Dataverse pour le confirmer.

Dépannage