Configuration de sécurité Dataverse-Native

Aperçu

Ce modèle de sécurité est actuellement en version avant-première — à la fois la fonctionnalité de sécurité unifiée sous-jacente de Microsoft Dataverse et le support de Power Portals Pro pour celle-ci. Power Portals Pro suit le calendrier de sortie de Microsoft : une fois que la fonctionnalité sera disponible en disponibilité générale chez Microsoft, le support de Power Portals Pro sera également disponible en version préliminaire. La désignation de prévisualisation existe pour tenir compte de toute modification que Microsoft pourrait apporter de son côté pendant la phase de prévisualisation.

Le modèle de sécurité natif Dataverse permet à Dataverse lui-même d’appliquer la sécurité pour vos utilisateurs de portails via des rôles de sécurité standards, configurés exactement comme Power Pages les configure — rôles web et permissions de table. Cette page présente toute la mise en place, d’un bout à l’autre.

Pour savoir comment fonctionne le modèle et comment il se rapporte aux gestionnaires de permissions, voir le Aperçu de la sécurité

1. Installer les composants du cadre Power Pages

Le modèle de sécurité unifié fonctionne sur des composants que Microsoft installe dans votre environnement Dataverse lors de la création d’un site Web Power Pages. Si l’environnement n’a jamais hébergé de site Power Pages, créez-en un maintenant — n’importe quel modèle fonctionne, et un site d’essai convient parfaitement. Voir Créer et gérer des sites dans la documentation Power Pages.

Note

Vous n’avez pas besoin de payer pour le site ni de le maintenir en fonctionnement — une fois les composants du framework installés et la fonction de sécurité activée, vous pouvez supprimer le site lui-même. L’enregistrement du site Power Pages (powerpagesite) référencé par votre configuration doit rester dans l’environnement, car les mappages utilisateur et la synchronisation sécurité-rôle se résolvent contre celui-ci.

2. Activer la sécurité unifiée Dataverse pour le site

Activez la fonctionnalité de sécurité unifiée Dataverse de Microsoft pour le site en suivant les étapes de la sécurité unifiée de Power Pages avec Dataverse. Une fois activée, la plateforme crée un rôle de sécurité Dataverse apparié (nommé) PowerPages_*pour chaque rôle web du site et le maintient synchronisé.

3. Configurer les rôles Web et les permissions de table

Dans l’application Power Pages Management , créez (ou ajustez) les rôles web et les permissions de table du site, et liez chaque permission de table aux rôles web qui devraient les recevoir. C’est la seule façon prise en charge pour accorder l’accès sous ce modèle — la plateforme traduit les permissions de table liée en privilèges pour chaque rôle de sécurité synchronisé du rôle web. Les oscillations fonctionnent exactement comme dans Power Pages (Global, Contact, Compte, ...), donc les règles d’accès au niveau des enregistrements sont également configurées ici.

4. Trouver l’identifiant de votre site Power Pages

PowerPortalsPro a besoin de l’identifiant de l’enregistrement du powerpagesite site. Vous pouvez interroger directement — par exemple, ouvrir <your org url>/api/data/v9.2/powerpagesites?$select=name dans un navigateur et copier le powerpagesiteid site de votre site.

5. Activer le provisionnement dans Power Portals Pro

Configurez SecurityOptions dans les fichiers de votre serveur Program.cs:

La configuration est validée au démarrage — lorsqu’elle ProvisionSystemUsers est activée, PowerPagesSiteId elle doit être définie et doit se résoudre à un enregistrement existant powerpagesite , sinon l’application ne démarre pas avec des instructions. À partir de ce moment, PowerPortalsPro fournit automatiquement un système géré par le système (C2) systemuser et un powerpagesusermapping enregistrement pour chaque contact du portail — à l’enregistrement des nouveaux contacts, et paresseusement à la connexion pour les contacts existants — et usurpe l’identité de cet utilisateur à chaque appel Dataverse.

6. Attribuer des rôles web aux contacts

Accordez l’accès aux utilisateurs individuels en attribuant des rôles web à leurs contacts — dans l’application Power Pages Management, ou de manière programmatique via la powerpagecomponent_mspp_webrole_contact relation. La plateforme attribue et supprime automatiquement les rôles de sécurité synchronisés à mesure que l’appartenance aux rôles web change.

Conseil

Dataverse met en cache les privilèges effectifs de chaque utilisateur par nœud serveur, donc les changements de rôle et de privilège peuvent prendre de quelques secondes à quelques minutes avant de prendre effet après une affectation. Tenez compte de cela dans les tests et dans tout flux qui accorde l’accès puis agissez immédiatement en conséquence.

Visiteurs anonymes

Les visiteurs déconnectés sont couverts par le même modèle. Power Pages crée automatiquement un utilisateur Anonyme pour le site — un utilisateur géré par le système avec cette identité PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — et PowerPortalsPro l’imite pour chaque requête non authentifiée. Accorder un accès anonyme à la manière de Power Pages : indiquer un rôle web comme le rôle d’Utilisateurs Anonymes du site dans l’application Power Pages Management et permettre de créer des liens vers la table ; Le rôle de sécurité synchronisé régit alors ce que les visiteurs déconnectés peuvent voir.

Note

L’utilisateur Anonyme est créé paresseusement par Power Pages, donc les sites créés avant la fonction de sécurité unifiée peuvent ne pas en avoir encore (elle est découverte via les enregistrements sans powerpagesusermapping contact du site — l’utilisateur lui-même est invisible aux requêtes d’attributs — et un candidat n’est accepté qu’après vérification de son identité par rapport au nom d’utilisateur Anonyme bien connu). Quand elle n’est pas trouvée, les visiteurs anonymes recourent aux gestionnaires de permissions côté portail — c’est-à-dire pas d’accès anonyme aux données à moins que les gestionnaires ne soient enregistrés — et le cadre enregistre le résultat au démarrage et réessaie périodiquement.

Qu’en est-il des gestionnaires de permissions ?

Les sessions sous ce modèle contournent ITablePermissionHandler / ITableRecordPermissionHandler sont totalement contournées — exactement comme les connexions internes systemuser — car Dataverse applique la sécurité nativement via les rôles de l’utilisateur usurpé. Vous n’avez pas besoin d’écrire ou d’enregistrer de code de gestionnaire d’autorisations. Les gestionnaires s’appliquent toujours aux sessions qui ne sont pas soutenues par un utilisateur système usurpé (la fonctionnalité désactivée, une session où le provisionnement a échoué et où le cadre est revenu à la sécurité côté portail, ou les visiteurs anonymes sur un site sans l’utilisateur Anonyme), de sorte que les portails existants basés sur les gestionnaires peuvent migrer progressivement.

Distinguer les utilisateurs provisionnés dans votre interface utilisateur

Les sessions portent une PortalUserType revendication contenant la valeur entière de l’enum PortalUserType : Contact (utilisateur classique du portail), SystemUser (connexion interne réelle), ou ContactStubUser (un contact soutenu par un utilisateur géré par le système provisionné) ; ContactStubUser les sessions transportent en outre une SystemUserId revendication avec l’identifiant de l’utilisateur provisionné, résolue à partir de l’enregistrement autoritaire powerpagesusermapping . Le même enum est retourné par GET /api/auth/me . CurrentUserInfo.PortalUserType Utilisez les GetPortalUserType() extensions et GetDataverseSystemUserId() sur ClaimsPrincipal, et ne présentez jamais une ContactStubUser session comme un utilisateur interne.

Référence API