Comment la sécurité de champ permet de contrôler l’accès aux valeurs des champs dans Microsoft Dynamics CRM 2015

Date de publication : novembre 2016

S’applique à : Dynamics CRM 2015

Dans Microsoft Dynamics CRM 2015 et Microsoft Dynamics CRM Online, utilisez la sécurité au niveau des champs pour limiter l'accès aux champs à fort impact sur les activités à des utilisateurs et des équipes spécifiques. Par exemple, utilisez cette option pour permettre à certains utilisateurs de lire ou de mettre à jour le score de crédit d'un client. Pour cette version, la sécurité au niveau du champ peut être appliquée à la fois aux champs personnalisés et à de nombreux champs prêts à l'emploi.

Les étapes suivantes montrent comment limiter l'accès à un champ :

1. Activation de la sécurité au niveau du champ pour un attribut

2. Création d'un profil de sécurité au niveau du champ

3. Association des utilisateurs ou des équipes au profil

4. Ajout d'autorisations spécifiques au champ, telles que la création, la mise à jour ou la lecture à un attribut spécifique du profil

Le diagramme suivant illustre l'interaction entre la sécurité basée sur les rôles, la sécurité basée sur les enregistrements et la sécurité au niveau du champ.

La sécurité basée sur les rôles vous permet d'afficher un type d'entité spécifique, la sécurité basée sur les enregistrements vous permet de consulter chaque enregistrement, et la sécurité au niveau des champs vous permet de voir des champs spécifiques.

Vidéo : Sécurité au niveau des champs dans Microsoft Dynamics CRM 2015

Forums Aux Questions (FAQ)

• Quels attributs peuvent être sécurisés ?

• Quels rôles de sécurité vous permettent de voir les champs sécurisés ?

• Comment les champs sécurisés se comportent-ils pour Retrieve et RetrieveMultiple ?

• Comment les champs sécurisés se comportent-ils pour la création ou la mise à jour ?

• Comment les champs sécurisés se comportent-ils lorsque des enregistrements sont partagés ?

• Comment les champs sécurisés se comportent-ils pour les vues filtrées ?

• Comment les champs sécurisés se comportent-ils pour la synchronisation hors ligne ?

Quels attributs peuvent être sécurisés ?

Pour afficher les attributs pouvant être sécurisés, vous pouvez interroger les métadonnées de l'entité pour les propriétés suivantes :

• CanBeSecuredForCreate

• CanBeSecuredForRead

• CanBeSecuredForUpdate

Il existe des milliers d'attributs pouvant être sécurisés. Il existe donc deux moyens plus simples de rechercher cette information.Pour afficher les métadonnées d'entité pour votre organisation, installez la solution Navigateur de métadonnées décrite dans l'article Parcourir les métadonnées de votre organisation. Vous pouvez également afficher les métadonnées d'une organisation non personnalisée dans un fichier Excel appelé EntityMetadata.xlsx dans le dossier de niveau supérieur du téléchargement du Kit de développement logiciel (SDK).

Il existe des règles supplémentaires qui s'appliquent à certains types de données d'attribut :

• Les attributs booléens peuvent être sécurisés pour les opérations de création et de mise à jour, mais pas pour la lecture.

• Les attributs de groupes d'options peuvent être sécurisés pour la création, la mise à jour et la lecture, lorsqu'une valeur par défaut n'est pas spécifiée.

Quels rôles de sécurité vous permettent de voir les champs sécurisés ?

Le profil de sécurité du champ Administrateur système donne l'accès complet à tous les champs sécurisés dans Microsoft Dynamics 365. Par défaut, tous les utilisateurs ayant le rôle de sécurité Administrateur système disposent de ce profil. Ce profil est géré par le système et ne peut pas être mis à jour ni supprimé.

Comment les champs sécurisés se comportent-ils pour Retrieve et RetrieveMultiple ?

Lorsque vous appelez la méthode ou le message Retrieve ou RetrieveMultiple, Microsoft Dynamics 365 évalue si l'appelant et l'utilisateur représenté ont accès à chaque enregistrement récupéré (il s'agit du processus de sécurité standard) et à chaque champ sécurisé. L'appel ne lève aucune exception si les critères contiennent les champs sécurisés auxquels l'appelant n'a pas accès. À la place, des valeurs Null sont retournées pour les champs sécurisés s'ils font partie de l'ensemble de colonnes de sortie.

Vous trouverez ci-dessous plus d'informations sur les différents comportements de récupération des champs sécurisés.

Lorsqu'un attribut sécurisé se trouve dans l'ensemble de colonnes

Si l'appelant (ou l'utilisateur représenté ) n'a pas accès en lecture aux champs sécurisés inclus dans un ensemble de colonnes, la valeur retournée est null. Vous ne pouvez pas faire la différence entre une valeur null retournée provoquée par l'absence de données ou provoquée par un accès insuffisant.

Lorsqu'un attribut sécurisé se trouve dans le critère de filtre

Si l'appelant (ou l'utilisateur représenté) n'a pas accès aux champs sécurisés inclus dans les critères de filtre, la valeur du champ est remplacée par null pendant l'évaluation du filtre.

Dans le tableau suivant, l'appelant a accès à tous les attributs, excepté ceux désignés par un astérisque (*).

Lorsque le filtre est CanbeContacted == True, seul l'enregistrement un est renvoyé.

Lorsque le filtre est IsNULL (CanbeContacted), les enregistrements 3 et 4 sont renvoyés. Comme l'enregistrement 3 n'est pas visible par l'utilisateur, il est traité en tant que valeur null pendant l'évaluation du critère et est évalué comme True pour ISNull.

Lors de l'agrégation sur la base des attributs sécurisés

Les valeurs sécurisées sont remplacées par une valeur null, par conséquent le comportement d'agrégation SQL normal s'applique.

Lors du regroupement sur la base des attributs sécurisés

Si l'appelant (ou l'utilisateur représenté) n'a pas accès à l'attribut utilisé pour le regroupement, la valeur est traitée comme étant null et les résultats sont regroupés avec toutes les valeurs null.

Dans l'exemple suivant, l'appelant a accès à certains attributs. Le format Gras n'indique pas d'accès aux attributs, également désignés par un *. Le format Italique désigne un enregistrement pour lequel l'appelant n'a pas d'accès en lecture, également désigné par **.

Select State, Total(orders) Group by (STATE) donne les résultats suivants :

WA–5

CA–4

null–2

Lors du classement sur la base des attributs sécurisés

Si l'appelant (ou l'utilisateur représenté ) n'a pas accès aux champs sécurisés inclus dans un ordre par condition, les valeurs seront traitées comme si elles étaient null.

Dans l'exemple suivant, l'appelant a accès aux attributs qui sont en texte brut. Le format Gras n'indique pas d'accès aux attributs, également désignés par un astérisque (*). Le format Italique désigne un enregistrement pour lequel l'appelant n'a pas d'accès en lecture, également désigné par **.

Select Name order by Description ascending donne les résultats suivants :

{G, E, C}, A, B, D seront renvoyés.

Comment les champs sécurisés se comportent-ils pour la création ou la mise à jour ?

Un programmeur peut générer un client qui utilise les méthodes Create et Update qui interagissent avec les champs sécurisés. Lorsque vous appelez la méthode Create ou Update, en transmettant des données pour les champs sécurisés et que l'appelant ne dispose pas d'autorisations suffisantes, une exception est levée.

Comment les champs sécurisés se comportent-ils lorsque des enregistrements sont partagés ?

Un utilisateur ayant accès à un champ sécurisé dans un enregistrement peut choisir de le partager avec un autre utilisateur ou une autre équipe. L'utilisateur peut uniquement accorder l'accès dont il dispose sur l'enregistrement. Par exemple, pour partager l'enregistrement et bénéficier des privilèges de mise à jour, l'utilisateur doit avoir des privilèges de mise à jour.

Vous pouvez partager un champ sécurisé sur un enregistrement spécifique avec la lecture et/ou la mise à jour avec un principal de sécurité (utilisateur ou équipe).  L'utilisateur ou les membres de l'équipe avec lesquels l'enregistrement a été partagé disposent maintenant de ce type d'accès de champ sécurisé uniquement sur les champs sécurisés partagés pour seulement cet enregistrement en particulier, même si l'utilisateur ou le membre de l'équipe avec lequel il a été partagé n'a pas de profil de sécurité de champ qui lui fournit l'acccès.

Comment les champs sécurisés se comportent-ils pour les vues filtrées ?

Un administrateur sécurise l'accès à un certain nombre de champs dans l'application et souhaite que ces champs ne soient pas disponibles dans les rapports. Cela permet de conserver le même ensemble de rapports pour tous les utilisateurs. Les vues filtrées ne renverront aucune donnée pour les champs sécurisés si l'utilisateur appelant n'a pas d'autorisation pour ces champs. Si aucune sécurité de champ n'est appliquée aux attributs de la vue, les vues filtrées retourneront des données complètes.

Comment les champs sécurisés se comportent-ils pour la synchronisation hors ligne ?

Si vous utilisez Microsoft Dynamics CRM pour Microsoft Office Outlook avec accès hors connexion, seules les valeurs de champ sécurisées auxquelles vous avez accès sont répliquées dans la base de données hors connexion. Si vous n'avez pas accès aux données, elles ne seront pas enregistrées hors connexion.

Voir aussi

Vidéo : Sécurité au niveau des champs dans Microsoft Dynamics CRM 2015
Modèle de sécurité de Microsoft Dynamics CRM 2015
Comment la sécurité basée sur les rôles permet de contrôler l'accès aux entités dans Microsoft Dynamics CRM 2015
Comment la sécurité basée sur les enregistrements permet de contrôler l'accès aux enregistrements dans Microsoft Dynamics CRM 2015

© 2017 Microsoft. Tous droits réservés. Copyright