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.

Dans ce modèle, le portail cesse de décider de ce qu’un utilisateur peut faire et Dataverse décide à sa place. Chaque contact portail est soutenu par son propre utilisateur Dataverse, chaque requête est faite en tant qu’utilisateur , et l’accès est ce que permettent les rôles de sécurité de cet utilisateur — le même modèle de sécurité qui régit une application pilotée par modèle. Rien dans le portail n’est consulté, et rien dans le portail ne peut l’élargir. Le hic est d’où viennent ces rôles : Dataverse permet à un utilisateur du portail provisionné de ne tenir qu’un rôle généré par la plateforme , et la seule chose qui les génère est Power Pages. Ce modèle s’appuie donc sur Power Pages d’une manière que le reste de Power Portals Pro ne fait jamais — l’étape 3 explique exactement jusqu’où cela va.

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

Soutenir un contact avec un utilisateur Dataverse repose sur une capacité de plateforme qui n’existe qu’une fois que les composants Power Pages sont dans l’environnement : l’utilisateur géré par le système, un enregistrement utilisateur qui ne coûte aucune licence et qui peut être usurpé d’identité. Si l’environnement n’a jamais hébergé un site Power Pages, créez-en un maintenant — n’importe quel modèle fonctionne, et un site d’essai convient. Voir Créer et gérer un site. Deux éléments découlent de ces composantes : l’utilisateur qui soutient chaque contact, et les rôles de sécurité que cet utilisateur est autorisé à occuper.

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, car chaque utilisateur provisionné est enregistré contre lui en powerpagesusermapping ligne — le lien entre un contact et l’utilisateur Dataverse qui le représente.

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. Accorder l’accès avec des rôles Web et des permissions de table

L’accès provient des rôles de sécurité détenus par l’utilisateur Dataverse derrière chaque contact — mais ce ne sont pas des rôles que vous pouvez écrire. Dataverse n’accepte qu’un rôle généré par le système sur un utilisateur de portail provisionné, et la seule chose qui les génère est la fonctionnalité que vous avez activée à l’étape 2 : elle crée un rôle jumelé PowerPages_* pour chaque rôle web sur le site, et la plateforme l’attribue ou le déassigne à mesure que l’adhésion au rôle web d’un contact change. Ce qu’un utilisateur du portail peut atteindre est donc déterminé par le rôle web et les permissions de table qui y sont attachées — éditées dans l’application Power Pages Management ou, avec la solution Power Portals Pro Enhanced Authorization installée, sur la page Web Roles de votre portail. C’est le seul endroit dans Power Portals Pro où un concept Power Pages décide ce que quelqu’un peut atteindre, et c’est une exigence de la plateforme plutôt que notre conception. Les enregistrements auxquels un utilisateur accède sont déterminés par la portée des permissions de chaque table, et non par la profondeur de propriété : chaque privilège sur un rôle généré porte un filtre d’enregistrement de plateforme dérivé de celui-ci. Lire une table peut atteindre une autre — lire un compte lit aussi ses adresses — donc ces tables associées doivent aussi obtenir des permissions de table. Voir Permissions de table.

Note

Pourquoi vous ne pouvez pas simplement assigner un rôle que vous avez créé vous-même. Vérifié dans un environnement propre : attribuer un rôle de sécurité ordinaire à un utilisateur de portail provisionné échoue avec « Le type d’utilisateur géré par le système n’est pas valide pour le rôle assigné », et la création d’un rôle marqué comme généré par le système via l’API est refusée par « Opération invalide effectuée ». La restriction est spécifique au type d’utilisateur que prévoit le portail — d’autres utilisateurs gérés par le système, comme un utilisateur applicatif, occupent des rôles ordinaires sans se plaindre.

4. Donner aux utilisateurs leurs rôles web

Un contact obtient l’accès d’un rôle web en maintenant ce rôle. Pour transmettre automatiquement les rôles web aux nouveaux utilisateurs, installez la solution Power Portals Pro Enhanced Authorization et ajoutez des règles sur la page Web Roles de votre portail (WebRoleAdminincluse dans les deux modèles de projet) : chaque règle donne un rôle web à chaque nouvel utilisateur, ou à ceux correspondant à une règle FetchXML sur les contacts. Les règles s’exécutent une fois par contact — lorsque le portail les enregistre, et lorsqu’un contact existant se connecte pour la première fois avec une connexion externe — donc un rôle web qu’un administrateur supprime plus tard reste supprimé. Vous pouvez également attribuer des rôles web à la main dans l’application Power Pages Management.

Note

La solution d’Autorisation Améliorée est distincte de Power Portals Pro Core car elle dépend de Power Pages. Pour attribuer des rôles web, l’utilisateur de l’application du portail doit lire sur la table de configuration des rôles web, lire et ajouter sur les rôles web, et lire les composants sur site (powerpagecomponent), où Power Pages stocke les rôles web. La page des rôles web fonctionne en tant qu’administrateur connecté, et Dataverse ne permet que ce que lui et l’utilisateur de l’application peuvent faire, donc l’utilisateur de l’application doit en plus créer et ajouter sur la table de configuration ; créer, écrire, supprimer et ajouter sur les rôles web ; créer, lire, écrire, supprimer, ajouter et ajouter sur les autorisations sur la table (mspp_entitypermission) ; créer, écrire et supprimer sur les composants du site ; et Appender sur les sites web (mspp_website), car chaque rôle web et chaque autorisation de table nomme le site auquel il appartient.

5. 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.

6. 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.

7. Vérifiez ce qu’un utilisateur peut réellement faire

Un utilisateur provisionné est créé dès la première connexion de son contact, donc la vérification la plus rapide est de se connecter en tant qu’utilisateur réel du portail et d’essayer ce qu’il doit ou ne doit pas pouvoir faire. Son accès est exactement ce que leur rôle de sécurité permet : aucune configuration côté portail ne se trouve devant, et rien dans le portail ne l’élargit.

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 mécanisme. La plateforme crée un utilisateur Anonyme géré par le système pour le site — l’identité PowerPages_00000000-0000-0000-0000-000000000000@<site id>.com — et Power Portals Pro l’imite pour chaque demande non authentifiée. Quels que soient les rôles de sécurité qu’occupe cet utilisateur, c’est ce qu’un visiteur anonyme peut atteindre, donc accordez-lui l’accès restreint en lecture seule qu’un visiteur déconnecté devrait avoir, et rien de plus.

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 de la sécurité de la table du portail ?

Les sessions sous ce modèle contournent tout ce que décrit une enregistrement de table — ses opérations, ses colonnes, son champ de portée et son tampon de propriété, que vous les ayez décrites avec AddTableAccess ou écrites — ITablePermissionProvider exactement comme les connexions internes systemuser , car Dataverse applique à la place. Les lignes qu’un utilisateur atteint et à qui appartient un enregistrement qu’il crée sont à leur rôle de sécurité, comme pour tout le reste. Vous n’avez pas besoin d’écrire ou d’enregistrer quoi que ce soit. Les enregistrements continuent de verrouiller des sessions qui ne sont pas soutenues par un utilisateur provisionné (la fonctionnalité désactivée, une session où le provisionnement a échoué et le cadre est revenu à la sécurité côté portail, ou des visiteurs anonymes sur un site sans l’utilisateur Anonyme), donc les portails existants peuvent migrer progressivement. Les rôles de portail ne s’appliquent pas non plus à ces sessions : ils ne sont ni attribués ni lus sous ce modèle.

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 . CurrentUserResponse.PortalUserTypeUtilisez les GetPortalUserType() extensions et GetDataverseSystemUserId() sur ClaimsPrincipal, et ne présentez jamais une ContactStubUser session comme utilisateur interne.

Les revendications de rôle suivent le même modèle. La session d’un utilisateur provisionné porte les rôles web qu’il détient — les noms attribués par un administrateur — ainsi que les PowerPages_* rôles de sécurité associés à eux, et aucun rôle de portail. Gate sur les rôles web avec [AuthorizeWebRole("Dealers")] ou <PortalRoleView WebRole="Dealers"> dans Blazor, et <AuthorizedView webRoles="Dealers"> dans React ; GET /api/auth/me les liste comme webRoles.

Référence API