Rôles explicites dans CSM

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 12 minutes de lecture

    • Vous pouvez donner l’accès à votre instance à la fois aux utilisateurs internes et aux utilisateurs externes. Toutefois, vous pourriez ne pas vouloir que les deux types d’utilisateurs aient le même niveau d’accès. Pour plus de sécurité, chaque utilisateur doit avoir au moins un rôle, afin que l’instance puisse distinguer les utilisateurs internes des utilisateurs externes.

    À partir de la Paris version, aucun utilisateur ne peut avoir les deux rôles explicites (snc_internal et snc_external). L’imbrication des groupes et des rôles ne peut pas non plus inclure les deux rôles, car cela entraînerait automatiquement les deux rôles pour tout membre du groupe ou utilisateur affecté à un tel groupe ou à tel rôle. Abandonne ServiceNow AI Platform toute opération qui créerait un tel scénario.

    Les utilisateurs externes doivent obtenir, au minimum, le rôle snc_external. Le rôle snc_external indique que l’utilisateur est externe à votre organisation. Ils ne doivent pas avoir accès aux ressources, sauf autorisation explicite par le biais des ACL pour le rôle snc_external ou des rôles supplémentaires qui héritent du rôle snc_external. Par défaut, les utilisateurs dotés du rôle snc_external ne peuvent pas accéder aux éléments suivants :
    • Tables sans le rôle qui hérite du rôle snc_external ou du rôle public.
    • Ressources de type autre qu’un enregistrement, telles que les processeurs et les pages de l’interface utilisateur sans accorder l’accès au rôle snc_external ou à un rôle qui hérite du rôle snc_external.
    • Platform Analytics tableaux de bord.

    Ne marquez pas le rôle snc_internal comme élevé. Sinon, les utilisateurs internes ne pourront pas accéder à l’instance.

    Rôles CSM recommandés pour les utilisateurs internes et externes

    Les clients (utilisateurs externes) qui utilisent l’application Customer Service Management (Gestion du service client) doivent se voir affecter le rôle sn_customerservice.customer ou sn_customerservice.consumer. Les agents du service client (utilisateurs internes) doivent être affectés au rôle sn_customerservice_agent ou sn_customerservice_consumer_agent. Le système veille à ce que le même utilisateur ne se voie pas affecter à la fois un rôle client (externe) et un rôle d’agent (interne).

    Module d’extension Rôles explicites

    Le module d’extension Service clientèle (com.sn_customerservice) active le module d’extension Rôles explicites (com.glide.explicit_roles), qui ajoute les rôles snc_external et snc_internal. Lorsque le module d’extension est activé :

    • Tous les utilisateurs doivent avoir le rôle snc_internal pour accéder aux ressources internes ou le rôle snc_external pour accéder aux ressources externes.
    • Tous les utilisateurs existants se voient automatiquement affecter le rôle de snc_internal. Ce rôle ne modifie pas les niveaux d’accès existants ni le comportement du système. Au lieu de cela, il fournit une catégorie pour différencier les utilisateurs internes des utilisateurs externes. Tous les utilisateurs internes conservent le même niveau d’accès qu’avant l’activation du module d’extension.
      Conseil :
      Pour éviter de modifier les fonctionnalités existantes pour les utilisateurs, l’activation du module d’extension Rôles explicites affecte le rôle d’utilisateur snc_internal à tous les utilisateurs existants dans l’instance. Cela inclut tous les utilisateurs externes ajoutés avant l’activation du module d’extension Rôles explicites. Une fois le module d’extension Rôles explicites activé, procédez comme suit pour tous les utilisateurs externes ajoutés avant l’activation du module d’extension Rôles explicites :
      • Supprimer le rôle snc_internal.
      • Ajoutez le rôle snc_external.
      Ce qui précède garantit que les utilisateurs externes ajoutés avant d’activer le module d’extension Rôles explicites n’ont pas accès à la ressource interne qui ne devrait être disponible que pour les utilisateurs internes.
    • Les utilisateurs nouvellement créés se voient automatiquement affecter le rôle de snc_internal lorsqu’ils tentent pour la première fois de se connecter à l’instance, sauf si le rôle de snc_external leur a été explicitement affecté. Vous pouvez ajouter le rôle snc_external à un nouvel utilisateur avant qu’il ne se connecte pour la première fois à l’instance afin de lui fournir des droits d’utilisateur externes.
      Important :
      Activez ce module d’extension pendant une fenêtre de maintenance ou lorsque peu d’utilisateurs sont connectés. Les utilisateurs actuellement connectés lorsque le module d’extension est activé ne se verront pas affecter dynamiquement le rôle snc_internal. Les utilisateurs doivent plutôt se déconnecter et se reconnecter pour se voir affecter le rôle snc_internal. Une fois le module d’extension activé, vous pouvez ajouter ou supprimer les rôles snc_internal et snc_external à tout moment pour modifier les droits des utilisateurs.
    • Toutes les ACL existantes qui n’ont pas d’exigence de rôle se voient automatiquement affecter le rôle snc_internal. Étant donné que les ACL et les rôles existants sont affectés au rôle snc_internal, les niveaux d’accès existants ne changent pas.
    • Les ACL nouvellement créées qui n’ont pas d’exigence de rôle se voient automatiquement affecter le rôle snc_internal. Cette affectation de rôle ne s’applique pas à une ACL nouvellement créée avec un rôle affecté.
    • Pour tous les enregistrements de processeur [sys_processor] existants ou les enregistrements de processeur [sys_processor] nouvellement créés avec Type=script, le rôle snc_internal est automatiquement ajouté au champ Rôles si le champ est vide.
    • Pour restreindre l’accès aux pages de l’interface utilisateur aux utilisateurs internes, le module d’extension affecte automatiquement le rôle de snc_internal à l’ACL * avec un type de ui_page.
    • Pour restreindre l’accès aux processeurs aux utilisateurs internes, le module d’extension affecte automatiquement le rôle de snc_internal à l’ACL * avec un type de processeur.
    • Les utilisateurs externes doivent obtenir, au minimum, le rôle snc_external pour accéder à l’instance. Ce rôle est automatiquement affecté aux contacts externes de Portail de service clientèle. Si le Customer Service Portal (Portail de service client) n’est pas activé, ce rôle doit être accordé manuellement aux utilisateurs externes. L’accès aux enregistrements est accordé par le biais d’ACL.
      Remarque :
      Vous pouvez utiliser la fonction isPublic() dans les scripts de Customer Service Portal (Portail de service client) pour modifier le paramètre de confidentialité d’un include de script unique pouvant être appelé par un client. Pour plus de détails, voir Includes de script.
    • L’accès au site du système de gestion de contenu est également affecté. CMS est configuré avec des sites (content_site), des pages (content_page) et d’autres ressources. La page de connexion peut être configurée sur certains sites.
      • Si la page de connexion n’est pas configurée pour les sites CMS, le rôle public est automatiquement ajouté au champ Rôles de lecture des pages (content_page) si le champ est vide.
      • Si la page de connexion est configurée pour les sites CMS, le rôle de snc_internal est automatiquement ajouté au champ Rôles de lecture des pages (content_page) si le champ est vide.
    • L’accès au site du portail de services est également affecté.

      Le rôle snc_internal n’est pas automatiquement ajouté aux enregistrements sp_page, sp_widget ou sp_instance. Si vous le souhaitez, vous pouvez attribuer le rôle à de nouveaux enregistrements en affectant snc_internal comme valeur par défaut dans le champ Rôles de ces enregistrements. Pour plus de détails sur ce processus, voir Spécifier une valeur de champ par défaut.

    Ne déplacez pas les ensembles de mises à jour système entre les instances avec ou sans le module d’extension Rôles explicites activé.

    Remarque :
    Ce module d’extension nécessite également le module d’extension Contextual Security Manager .

    La propriété glide.security.explicit_roles.internal_user_blacklist

    Le module d’extension Rôles explicites suppose que tous les utilisateurs existants dans la table sys_user au moment de l’installation du module d’extension sont des clients internes. Un script correctif affecte le rôle snc_internal à tous les utilisateurs existants et à toute ACL qui n’a pas de rôle.

    Le script correctif peut échouer ou ne pas se terminer à temps pour un utilisateur qui n’a pas été mis à jour avec le rôle et qui tente d’accéder à une ressource. Pour combler cette lacune potentielle, le gestionnaire de sécurité contextuelle (CSM) affecte automatiquement le rôle snc_internal à tout utilisateur qui se connecte et qui ne dispose pas d’un rôle explicite (interne ou externe).

    En outre, CSM dispose d’un processus de règle métier qui affecte le rôle snc_external à une classification de ses utilisateurs. Toutefois, lors de l’importation de grands ensembles de clients externes CSM, le workflow est défini sur faux, de sorte que les règles métier ne s’exécutent pas. Lorsque ces utilisateurs tentent d’accéder à une ressource, ils n’ont pas de rôles explicites. Le gestionnaire de sécurité contextuelle affecte le rôle de snc_internal via une tâche planifiée appelée Rapport sur les écarts et les conflits d’astreinte, qui s’exécute tous les 7 jours. Lorsque le module d’extension Rôles explicites est actif, ce travail affecte le rôle snc_internal à l’utilisateur externe CSM, car l’utilisateur ne dispose ni du rôle snc_internal ni du rôle snc_external.

    Pour éviter de fournir par inadvertance le rôle snc_internal à des utilisateurs externes, le module d’extension Rôles explicites inclut une glide.security.explicit_roles.internal_user_blacklist propriété permettant d’empêcher des types d’utilisateurs de devenir des snc_internal. Si aucun type d’utilisateur n’est présent dans la table glide.security.explicit_roles.internal_user_blacklist, le gestionnaire de sécurité contextuelle affecte le rôle de snc_internal à tous les utilisateurs par défaut. Si la table de la liste noire contient des noms de classe et si le type de classe sys_user se trouve dans la table de la liste noire, CSM affecte le rôle snc_external. Sinon, CSM affecte le rôle de snc_internal par défaut comme d’habitude.

    Pour la version, cette propriété est activée par défaut pour les instances zBoot et désactivée par défaut pour les Paris mises à niveau.

    Fournir l’accès aux tables aux utilisateurs externes

    Vous pouvez fournir aux utilisateurs externes l’accès à une table en ajoutant un rôle à la table qui hérite du rôle snc_external. Pour plus d'informations, consultez Fournir aux utilisateurs externes l’accès à une table.

    La méthode hasRoles()

    La méthode hasRoles() est toujours disponible, mais elle est obsolète dans la Geneva version. Utilisez plutôt la méthode hasRole(nom du rôle).

    Si vous utilisez la méthode hasRoles(), notez les changements suivants :
    • Cette méthode exclut automatiquement le rôle de snc_internal par défaut lorsqu’elle recherche des rôles. Cela signifie que si un utilisateur n’a que le rôle snc_internal, la méthode hasRoles() renvoie toujours false.
    • Si l’utilisateur dispose du rôle snc_external, la méthode renvoie la valeur faux , car l’instance considère que les utilisateurs externes n’ont pas de rôle.

    Exclusion mutuelle : snc_external ou snc_internal

    Cela ServiceNow AI Platform empêche les utilisateurs d’avoir à la fois le rôle snc_external et le rôle snc_internal. L'application ServiceNow AI Platform applique cette exclusion mutuelle partout dans le système et saisit des messages d'erreur dans les journaux pour chaque conflit.
    Remarque :
    Les ACL peuvent avoir les deux rôles si les ressources ACL doivent être accessibles à tous les utilisateurs.
    Exemple : ajout des deux rôles explicites à un utilisateur (collision directe) :
    1. Affectez à l’utilisateur Abel Tuter le rôle snc_internal.
    2. Affectez à l’utilisateur Abel Tuter le rôle snc_external.

    Résultat : l’ajout du rôle snc_external échoue car Abel Tuter a le rôle snc_internal.

    Exemple : ajout des deux rôles explicites à un groupe (collision directe) :

    1. Prenons l’exemple d’un groupe appelé Groupe de tests qui n’a actuellement aucun rôle explicite affecté au groupe.
    2. Ajoutez Abel Tuter au groupe de tests.
    3. Ajoutez le rôle snc_external au groupe de tests.

    Résultat : l’ajout du rôle snc_external échoue, car Abel Tuter a déjà le rôle snc_internal et ne peut pas avoir les deux rôles.

    Exemple : ajout d’un rôle explicite à un groupe où un membre du groupe a un rôle explicite en conflit (collision indirecte) :
    1. Affectez à l’utilisateur Abel Tuter le rôle snc_internal.
    2. Prenons l’exemple d’un groupe appelé Groupe de tests qui n’a actuellement aucun rôle explicite affecté au groupe.
    3. Ajoutez Abel Tuter au groupe de tests.
    4. Ajoutez le rôle snc_external au groupe de tests.

    Résultat : l’ajout du rôle snc_external au groupe échoue, car Abel Tuter hériterait du rôle snc_external via l’appartenance au groupe. Les deux rôles explicites seraient affectés au même utilisateur, ce qui n’est pas autorisé.

    Pour obtenir d’autres exemples, consultez le tableau suivant :

    Rôle Tentative d’action Résultat
    Collision directe
    L’utilisateur dispose du rôle snc_internal. Ajoutez le rôle snc_external. L’action est abandonnée.
    L’utilisateur dispose du rôle snc_external. Ajoutez le rôle snc_internal. L’action est abandonnée.
    L’utilisateur n’a pas de rôle explicite. Ajoutez le rôle snc_internal ou snc_external. Le rôle est ajouté.
    L’utilisateur dispose des deux rôles explicites (collision existante). Ajouter l’utilisateur à un groupe sans rôle. L’action est abandonnée.
    Un rôle non associé à un utilisateur contient le rôle snc_internal. Ajoutez le rôle snc_external. L’action est abandonnée.
    Un rôle non associé à un utilisateur contient le rôle snc_external. Ajoutez le rôle snc_internal. L’action est abandonnée.
    Un rôle contient les deux rôles explicites (collision existante). Ajoutez le rôle à un utilisateur, à un rôle ou à un groupe. L’action est abandonnée.
    Un groupe sans membres a le rôle snc_internal. Ajoutez le rôle snc_external. L’action est abandonnée.
    Un groupe sans membre a le rôle snc_external. Ajoutez le rôle snc_internal. L’action est abandonnée.
    Un groupe sans membres n’a pas de rôles. Ajoutez le rôle snc_internal ou snc_external. Le rôle est ajouté.
    Collision indirecte
    Confinement du rôle avec collision
    1. Accordez un rôle appelé Rôle de test à un utilisateur disposant du rôle snc_internal.
    2. Ajoutez le rôle snc_external test.
    		 L’action est abandonnée.
    Confinement des rôles sans collision
    1. Accordez un rôle appelé Rôle de test à un utilisateur sans rôle.
    2. Ajoutez le rôle snc_external au rôle de test.
    		 Le rôle est ajouté à la fois au rôle d’utilisateur et au rôle de test.
    Confinement du groupe avec collision
    1. Ajoutez un utilisateur disposant du rôle snc_internal à un groupe appelé Groupe de tests 2 (enfant du groupe de tests 1).
    2. Ajoutez le rôle snc_external au groupe de tests 2.
    3. Ajoutez le rôle snc_external à un groupe parent appelé Groupe de tests 1 (parent du groupe de tests 2).
    		 L’action est abandonnée.
    Confinement du groupe sans collision
    1. Ajouter un utilisateur sans rôle à un groupe appelé Groupe de tests 2 (enfant du groupe de tests 1).
    2. Ajoutez le rôle snc_external ou snc_internal au groupe de tests 1 (parent du groupe de tests 2).
    		 Le rôle est ajouté au groupe parent, au groupe enfant et à l’utilisateur.
    Confinement du groupe et rôle de confinement avec collision Ajoutez contains_external au groupe de tests 1, parent du groupe de tests 2. Le groupe de tests 1 et le groupe de tests 2 obtiennent tous deux contains_external, mais n’obtiennent pas explicitement le rôle snc_external.
    Ajoutez le rôle snc_internal au groupe de tests 2, enfant du groupe de tests 1. L’action est abandonnée.
    Changement parent du groupe et imbrication des groupes
    1. Supprimez le groupe de tests 1 en tant que parent du groupe de tests 2.
    2. Ajoutez le rôle snc_internal au groupe de tests 1.
    3. Ajoutez le rôle snc_external au groupe de tests 2.
    4. Dans le groupe de tests 2, définissez le groupe de tests 1 comme groupe parent et enregistrez.
    		 L’action est abandonnée.

    Répétez l’opération pour les groupes déjà imbriqués, avec la même attente.

    La cause d’une action abandonnée apparaît dans le message d’erreur et doit être traitée avant qu’une autre tentative ne réussisse.

    Pour les tickets directs, tels que l’ajout d’un rôle explicite à un utilisateur individuel, vérifiez le rôle explicite que l’utilisateur doit avoir. Si l’utilisateur a le mauvais rôle explicite, il doit d’abord le supprimer, puis le rôle explicite correct doit être ajouté.

    Pour les tickets indirects, tels que l’ajout d’un rôle explicite à un groupe (afin qu’un membre du groupe se voie affecter les deux rôles explicites), évaluez si cet utilisateur doit faire partie du groupe. Déterminez également si le groupe doit recevoir le rôle explicite, y compris tout héritage via la hiérarchie des groupes et l’imbrication des rôles.

    Notez que le ServiceNow AI Platform rapport ne signale que la première collision potentielle rencontrée. Si des tentatives répétées continuent d’échouer après la correction, avec une nouvelle cause première à chaque fois, réévaluez plus largement l’interdépendance utilisateur/groupe/rôle pertinente. Vous pouvez repenser la structure des groupes et des limitations de rôles.