Configurer la sécurité à l’aide des autorisations de table
Notes
À compter du 12 octobre 2022, le portail Power Apps devient Power Pages. Plus d’informations : Microsoft Power Pages est maintenant généralement disponible (blog)
Nous allons bientôt migrer et fusionner la documentation des portails Power Apps avec la documentation de Power Pages.
Pour appliquer la sécurité dans des portails à des enregistrements individuels, utilisez des autorisations de table. Vous ajoutez des autorisations de table aux rôles web afin de pouvoir définir des rôles dans votre organisation qui correspondent logiquement aux privilèges et aux concepts de propriété d’enregistrement et d’accès. N’oubliez pas qu’un contact donné peut appartenir à n’importe quel nombre de rôles et qu’un rôle donné peut contenir un nombre illimité d’autorisations de table. Pour plus d’informations : Créer des rôles Web pour les portails.
Bien que les autorisations de modification et d’accès aux URL dans un plan de site de portail soient accordées par le biais de l’autorisation de contenu, les gestionnaires de sites voudront également sécuriser leurs applications web personnalisées créées avec des formulaires de table et des listes de table. Pour plus d’informations : Définir les formulaires de base et Définir des listes.
Pour sécuriser ces fonctionnalités, les autorisations de table permettent d’accorder des droits granulaires d’activer la sécurité au niveau des enregistrements par le biais des définitions de relations.
Ajouter des autorisations de table à un rôle web
Ouvrez l’application Gestion du portail.
Aller à Portails > Rôles web et ouvrez le rôle web auquel vous souhaitez ajouter des autorisations.
En dessous de Association, sélectionnez Autorisations de table.
Sélectionnez Ajouter une autorisation de table existante pour ajouter une autorisation de table existante à un rôle web.
Recherchez une autorisation de table ou sélectionnez Nouvelle autorisation de table pour créer un enregistrement d’autorisation de table.
Lors de la création d’un enregistrement d’autorisation de table, la première étape consiste à déterminer la table qui sera sécurisée. L’étape suivante consiste à définir le type d’accès, comme indiqué dans la section suivante, et — pour tout type d’accès autre que Global — les Relations qui définissent ce type d’accès. Enfin, déterminez les droits accordés au rôle par le biais de cette autorisation. Les droits peuvent se cumuler. Ainsi, si un utilisateur est dans un rôle qui octroie des droits de lecture et un autre qui accorde la lecture et la mise à jour, l’utilisateur a des droits de lecture et de mise à jour pour tous les enregistrements qui se chevauchent entre les deux rôles.
Notes
La sélection de tables comme une page web, des fichiers web et d’autres tables de configuration, n’est pas valide et peut avoir d’autres conséquences imprévues. Le portail déterminera la sécurité des tables de configuration en fonction des contrôles d’accès au contenu, et non des autorisations de table.
Type d’accès global
Si un enregistrement d’autorisation de table contenant des droits de Lecture pour un rôle qui a un type d’accès global, tout contact de ce rôle a accès à tous les enregistrements de table définie. Par exemple, ils peuvent afficher tous les prospects, les comptes, etc. Cette autorisation sera automatiquement respectée par toutes les listes d’entités, elle affiche tous les enregistrements s’accordant aux vues Microsoft Dataverse définies pour cette liste. De plus, si un utilisateur tente d’accéder à un enregistrement par le biais d’un formulaire de base auquel il n’a pas accès, il recevra une erreur d’autorisation. Par exemple, consultez cet exemple de scénario pour afficher toutes les annonces de voitures à tous les utilisateurs authentifiés dans un concessionnaire automobile.
Type d’accès au contact
Avec le type d’accès au contact, un utilisateur connecté dans le rôle pour lequel l’enregistrement d’autorisation est défini, disposera des droits accordés par cette autorisation uniquement pour les enregistrements associés à l’enregistrement Contact de cet utilisateur via les relations définies.
Dans une liste, ce type d’accès signifie qu’un filtre sera appliqué à toutes les vues Microsoft Dataverse apparaissant dans cette liste, qui récupère uniquement les enregistrements directement liés à l’utilisateur actuel. (Selon le scénario, cette relation peut être considérée comme des droits de propriété ou de gestion.) Par exemple, consultez cet exemple de scénario pour afficher, mettre à jour et supprimer les listes de voitures détenues dans un concessionnaire automobile.
Les formulaires de base n’accordent l’autorisation appropriée pour la lecture, la création, l’écriture, etc., que si cette relation existe lors du chargement de l’enregistrement. Plus d’information : Définir les formes de base.
Type d’accès au compte
Avec un type d’accès Compte, un utilisateur connecté dans le rôle pour lequel l’enregistrement d’autorisation est défini, disposera des droits accordés par cette autorisation uniquement pour les enregistrements associés à l’enregistrement Compte parent de cet utilisateur via une relation définie.
Ce type d’accès signifie que la liste n’affichera que les enregistrements de la table sélectionnée qui sont associés au Compte parent de l’utilisateur. Par exemple, si une autorisation de table autorise l’accès en lecture à une table Prospect avec le type d’accès Compte, l’utilisateur disposant de cette autorisation peut afficher tous les prospects du Compte parent de l’utilisateur uniquement. Par exemple, consultez cet exemple de scénario pour permettre au personnel de voir tous les concessionnaires automobiles appartenant à leur entreprise.
Type d’accès autonome
Le type d’accès Autonome vous permet de définir les droits d’un utilisateur sur son propre enregistrement (d’identité) de contact. Les utilisateurs peuvent utiliser des formulaires de base ou des formulaires à plusieurs étapes pour apporter des modifications à leur propre enregistrement de contact lié à leur profil. La page Profil par défaut intègre un formulaire spécial qui permet à tout utilisateur de modifier ses informations de contact de base, et de s’inscrire ou de se retirer des listes de marketing. Si ce formulaire est inclus dans votre portail (il l’est par défaut), les utilisateurs n’ont pas besoin de cette autorisation pour l’utiliser. Cependant, ils auront besoin de cette autorisation pour utiliser tout autre formulaire de base personnalisé ou formulaire à plusieurs étapes ciblant leur enregistrement de contact utilisateur. Par exemple, consultez cet exemple de scénario qui permet au personnel d’un concessionnaire automobile de mettre à jour ses coordonnées sur leur page de profil.
Type d’accès parent
Dans le cas le plus complexe, des autorisations sont accordées à une table qui est une relation de deuxième niveau d’une table pour laquelle un enregistrement Autorisation de table a déjà été défini. Cette autorisation est en fait un Enregistrement enfant de Autorisation de la table parent.
L’enregistrement d’autorisation parent définit une autorisation et un type d’accès pour une table (probablement un type d’accès globale ou du contact, bien qu’un parent soit également possible). Cette table peut être liée à un contact (dans le cas d’un type d’accès au contact) ou définie globalement. Avec cette autorisation en place, une Autorisation enfant est créée qui définit une relation entre une autre table et la table définie dans la relation parent.
Les utilisateurs d’un rôle web qui ont accès aux enregistrements définis par l’Autorisation de table parente auront également les droits définis par l’enregistrement de l’Autorisation enfant sur les enregistrements liés à l’enregistrement parent.
Attributs et relations
La table ci-dessous explique les attributs d’autorisation de table.
| Nom | Description |
|---|---|
| Nom | Nom descriptif de l’enregistrement. Ce champ est obligatoire. |
| Nom de table | Le nom logique de la table à sécuriser ou qui définira la relation de contact ou la relation du parent pour sécuriser une table associée sur une autorisation enfant. Ce champ est obligatoire. |
| Type d’accès (obligatoire) |
|
| Relation pour le type d’accès | Dépend du type d’accès sélectionné.
Remarque : disponible Relations sera vide si le Contact ou le Compte n’a pas de Relations existant avec la table sélectionnée. Pour créer la table Relations, voir Tableau Relations Vue d’ensemble. |
| Lu | Privilège qui contrôle si l’utilisateur peut lire un enregistrement. |
| Écriture | Privilège qui contrôle si l’utilisateur peut mettre à jour un enregistrement. |
| Créer | Privilège qui contrôle si l’utilisateur peut créer un enregistrement. Le droit de créer un enregistrement pour un type de table ne s’applique pas à un enregistrement individuel, mais à une classe de tables. |
| Suppr | Privilège qui contrôle si l’utilisateur peut supprimer un enregistrement. |
| Ajouter | Privilège qui vérifie si l’utilisateur peut joindre un autre enregistrement à l’enregistrement spécifié. Les droits d’accès Ajouter et Ajouter à sont associés. Chaque fois qu’un utilisateur joint un enregistrement à un autre, il doit disposer des deux droits. Par exemple, lorsque vous joignez une note à un cas, vous devez disposer du droit d’accès Ajouter sur la note et du droit d’accès Ajouter à sur le cas pour que l’opération fonctionne. |
| Ajouter à | Privilège qui vérifie si l’utilisateur peut ajouter l’enregistrement en question à un autre enregistrement. Les droits d’accès Ajouter et Ajouter à sont associés, comme décrit ci-dessus. |
Autorisations globales pour les tâches liées aux prospects
Dans un scénario, nous souhaitons peut-être utiliser une liste et des formulaires de base pour faire apparaître tous les prospects du portail à toute personne disposant d’un rôle web Gestionnaire de prospects personnalisé. Sur le formulaire de modification de prospects, qui est lancé chaque fois qu’une ligne de prospect est sélectionnée dans la liste, une sous-grille affichera les enregistrements de tâches associés. Ces enregistrements doivent être accessibles à toute personne occupant le rôle de Gestionnaire de prospects. Dans un premier temps, nous accorderons des autorisations globales aux prospects à toute personne faisant partie de notre rôle de Gestionnaire de prospects.
Ce rôle possède une autorisation de table associée pour la table de prospect, avec un type d’accès global.
Les utilisateurs de ce rôle peuvent accéder à tous les prospects par le biais des listes de tables ou par le biais des formulaires sur le portail.
Nous allons maintenant ajouter une autorisation enfant à l’autorisation globale de prospects. L’enregistrement de l’Autorisation parentale étant ouvert, accédez à la sous-grille Autorisations de table enfant et sélectionnez Nouvelle autorisation de table pour ajouter un nouvel enregistrement.
Sélectionnez la table en tant que Tâches et le type d’accès en tant que Parent. Vous pouvez ensuite sélectionner la relation parent (Lead_Tasks). Cette autorisation implique qu’un contact avec un rôle web avec l’Autorisation parent aura alors une Autorisation globale pour toutes les tâches liées aux prospects.
Pour que votre liste respecte ces autorisations :
Les autorisations de table doit être activé sur la liste.
Il doit y avoir des actions qui permettront réellement aux utilisateurs d’effectuer les actions pour lesquelles leurs autorisations ont été accordées.
Les autorisations doivent également être activées sur l’enregistrement formulaire basique.
Le formulaire doit apparaître sur une page contenant une sous-grille pour la table que vous souhaitez activer avec des Autorisations enfant. Dans ce cas, la table sera Tâches.
Pour activer les autorisations de lecture ou de création pour les tâches, vous devez également configurer ces formulaires de base et modifier les formulaires pour supprimer le champ de recherche Concernant.
Cette action permet d’accorder des autorisations pour toutes les tâches liées aux prospects. Si des tâches apparaissent dans une liste, un filtre est ajouté à la liste afin que seules les tâches liées à un prospect apparaissent dans la liste. Dans notre exemple, ils sont appelés avec une sous-grille sur un formulaire de base.
Autorisations de type d’accès aux contacts pour les tâches
Un autre exemple serait si vous souhaitiez autoriser l’accès aux tâches pour lesquelles un contact est lié au prospect parent pour cette tâche. Ce scénario est presque identique à l’exemple de la section précédente, sauf que dans ce cas, l’Autorisation parent a un type d’accès défini sur Contact, au lieu de Global. Une relation doit être spécifiée sur la relation parent entre la table Prospect et la table Contact.
Une fois ces autorisations en place, les utilisateurs du rôle Gestionnaire de prospects peuvent accéder aux prospects qui leur sont directement liés, comme spécifié par l’Autorisation du type d’accès Contact, et accéder aux tâches liées à ces mêmes prospects, tel que spécifié par l’Autorisation enfant.
Voir aussi
Créer des rôles Web pour les portails
Contrôler l’accès des pages Web pour les portails
Notes
Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)
Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).