Explicit Roles dans CSM

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 12 minutes de lecture

    • Vous pouvez donner l'accès à votre instance à la fois aux utilisateurs internes et aux utilisateurs externes. Cependant, vous ne souhaitez peut-être pas donner le même niveau d'accès à ces deux types d'utilisateurs. Pour fournir une sécurité accrue, chaque utilisateur doit avoir au moins un rôle afin que l'instance puisse faire la distinction entre les utilisateurs internes et externes.

    Pour la version Paris, aucun utilisateur ne peut avoir les deux rôles explicites (snc_internal et snc_external). Les groupes et le rôle de confinement ne peuvent pas inclure les deux rôles, car cela aurait pour conséquence qu'un membre du groupe ou un utilisateur qui est affecté à un tel groupe ou un tel rôle recevrait automatiquement les deux rôles. Now Platform abandonne toute opération qui créerait un tel scénario.

    Les utilisateurs externes doivent au minimum obtenir le rôle snc_external. Le rôle snc_external indique que l'utilisateur est externe à votre organisation. Il ne doit pas avoir accès aux ressources à moins d'y être explicitement autorisé par les ACL pour le rôle snc_external ou pour 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 :
    • Ressources Scripted REST API qui ne sont pas marquées comme étant externes.
    • Tables sans le rôle qui hérite du rôle snc_external ou du rôle public.
    • Ressources qui ne sont pas de type 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.
    • Tableaux de bord Now Intelligence.

    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) utilisant l'application Customer Service Management doivent se voir affecter le rôle sn_customerservice.customer ou sn_customerservice.consumer. Les agents du service client (utilisateurs internes) doivent se voir affecter le rôle sn_customerservice_agent ou sn_customerservice_consumer_agent. Le système vérifie que le même utilisateur n'est pas doté à la fois d'un rôle de client (externe) et d'un rôle d'agent (interne).

    Module d'extension Explicit Roles

    Le module d'extension Customer Service (com.sn_customerservice) active le module d'extension Explicit Roles (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 affecter automatiquement le rôle 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 maintiennent 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 Explicit Roles affecte le rôle d'utilisateur snc_internal à tous les utilisateurs existants dans l'instance. Cela inclut tous les utilisateurs externes ajoutés avant que le module d'extension Explicit Roles ait été activé. Après avoir activé le module d'extension Explicit Roles, effectuez les actions suivantes pour tous les utilisateurs externes ajoutés avant l'activation du module d'extension Explicit Roles :
      • Supprimez le rôle snc_internal.
      • Ajoutez le rôle snc_external.
      Cela garantit que les utilisateurs externes ajoutés avant l'activation du module d'extension Explicit Roles n'ont pas accès aux ressources internes qui ne doivent être disponibles que pour les utilisateurs internes.
    • Les utilisateurs nouvellement créés se voient affecter automatiquement le rôle snc_internal lorsqu'ils tentent pour la première fois de se connecter à l'instance, à moins que le rôle snc_external ne leur ait é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 pour lui fournir des droits d'utilisateur externe.
      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 attribuer 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 changer les droits des utilisateurs.
    • Tous les ACL existants qui n'ont pas de rôle requis se voient affecter automatiquement le rôle snc_internal. Étant donné que le rôle snc_internal est affecté aux ACL comme aux rôles existants, les niveaux d'accès existants ne changent pas.
    • Les ACL nouvellement créés qui n'ont pas de rôle requis se voient affecter automatiquement le rôle snc_internal. Cette affectation de rôle ne s'applique pas à un ACL nouvellement créé 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 celui-ci 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 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 snc_internal à l'ACL * avec un type de processeur.
    • Les utilisateurs externes doivent au minimum obtenir le rôle snc_external pour accéder à l'instance. Ce rôle est automatiquement affecté aux contacts externes du Customer Service Portal. Si le Customer Service Portal n'est pas activé, ce rôle doit être accordé manuellement aux utilisateurs externes. L'accès aux enregistrements est accordé par l'intermédiaire des ACL.
      Remarque :
      vous pouvez utiliser la fonction isPublic() dans les scripts pour Customer Service Portal afin de modifier le paramètre de confidentialité pour un seul script include de client pouvant être appelé. Pour plus de détails, consultez Script includes.
    • L'accès au site Content Management System est également concerné. CMS est configuré avec des sites (content_site), des pages (content_page) et d'autres ressources. Certains des sites peuvent avoir une Page de connexion configurée.
      • Si les sites CMS ne disposent pas de Page de connexion configurée, le rôle public est automatiquement ajouté au champ Rôles de lecture sur les pages (content_page) si le champ est vide.
      • Si les sites CMS disposent d'une Page de connexion configurée, le rôle snc_internal est automatiquement ajouté au champ Rôles de lecture sur les pages (content_page) si le champ est vide.
    • L'accès au site Service Portal est également concerné.

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

    Ne déplacez pas les ensembles de mises à jour système entre les instances avec et sans le module d'extension Explicit Roles activé.

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

    Propriété glide.security.explicit_roles.internal_user_blacklist

    Le module d'extension Explicit Roles suppose que tous les utilisateurs existants de 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 à n'importe quelle liste ACL sans 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 cet écart potentiel, le gestionnaire de sécurité contextuelle (CSM) affecte automatiquement le rôle snc_internal à tout utilisateur qui se connecte et qui n'a pas de rôle explicite (interne ou externe).

    En outre, le gestionnaire 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 de CSM, le workflow est défini sur faux et 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 CSM affecte le rôle snc_internal via une tâche planifiée appelée Rapport sur les écarts et conflits d'astreinte qui s'exécute tous les 7 jours. Lorsque le module d'extension Explicit Roles est actif, cette tâche affecte le rôle snc_internal à l'utilisateur externe de CSM, car il n'a ni le rôle snc_internal ni le rôle snc_external.

    Pour éviter de fournir le rôle snc_internal par inadvertance aux utilisateurs externes, le module d'extension Explicit Roles inclut une propriété glide.security.explicit_roles.internal_user_blacklist qui permet d'exclure des types d'utilisateurs pour ne jamais leur affecter le rôle snc_internal. Si la table glide.security.explicit_roles.internal_user_blacklist ne contient aucun type d'utilisateur, le gestionnaire CSM affecte par défaut le rôle snc_internal à tous les utilisateurs. Si cette table contient des noms de classes ainsi que le type de classe sys_user, le gestionnaire CSM affecte le rôle snc_external. Dans le cas contraire, le gestionnaire CSM affecte le rôle snc_internal par défaut comme d'habitude.

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

    Fournir l'accès aux tables aux utilisateurs externes

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

    La méthode hasRoles()

    La méthode hasRoles() est toujours disponible, mais elle est déconseillée dans la version Geneva. Utilisez plutôt la méthode hasRole(nom de rôle).

    Si vous utilisez la méthode hasRoles(), notez les changements suivants :
    • Cette méthode exclut automatiquement le rôle snc_internal par défaut lorsqu'elle vérifie les rôles. Cela signifie que si un utilisateur possède uniquement le rôle snc_internal, la méthode hasRoles() renvoie toujours la valeur faux.
    • Si l'utilisateur possède le 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 contre snc_internal

    Now Platform empêche les utilisateurs d'avoir le rôle snc_external et le rôle snc_internal à la fois. L'application Now 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 de 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 déjà le rôle snc_internal.

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

    1. Considérez 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 dans lequel un membre du groupe a déjà le rôle explicite en conflit (collision indirecte) :
    1. Affectez à l'utilisateur Abel Tuter le rôle snc_internal.
    2. Considérez 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érite du rôle snc_external en appartenant au groupe. Les deux rôles explicites seront affectés au même utilisateur, ce qui n'est pas autorisé.

    Pour d'autres exemples, consultez la table suivante :

    Rôle Tentative d'action Résultat
    Collision directe
    L'utilisateur a le rôle snc_internal. Ajoutez le rôle snc_external. L'action est abandonnée.
    L'utilisateur a le 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 les rôles snc_external et snc_internal. Le rôle est ajouté.
    L'utilisateur a les deux rôles explicites (collision existante). Ajoutez l'utilisateur à un groupe sans rôles. L'action est abandonnée.
    Un rôle qui n'est associé à aucun utilisateur a le rôle snc_internal. Ajoutez le rôle snc_external. L'action est abandonnée.
    Un rôle qui n'est associé à aucun utilisateur contient le rôle snc_internal. 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 membre 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 membre n'a aucun rôle. Ajoutez les rôles snc_external et snc_internal. Le rôle est ajouté.
    Collision indirecte
    Confinement de rôle avec collision
    1. Accordez un rôle appelé Rôle de test à un utilisateur avec le rôle snc_internal.
    2. Ajoutez le rôle snc_external au rôle de test.
    		 L'action est abandonnée.
    Confinement de rôle 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 à l'utilisateur et au rôle de test.
    Confinement de groupe avec collision
    1. Ajoutez un utilisateur qui a le 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 de groupe sans collision
    1. Ajoutez 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 de groupe et confinement de rôle avec collision Ajoutez contains_external au groupe de tests 1, le parent du groupe de tests 2. Le groupe de tests 1 et le groupe de tests 2 obtiennent tous les deux contains_external, mais n'obtiennent pas explicitement le rôle snc_external.
    Ajoutez le rôle snc_internal au groupe de tests 2, l'enfant du groupe de tests 1. L'action est abandonnée.
    Changement de groupe parent plus confinement de groupe
    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 en tant que groupe parent et enregistrez.
    		 L'action est abandonnée.

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

    La cause d'une action abandonnée s'affiche dans le message d'erreur et doit être traitée avant la réussite d'une autre tentative.

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

    Pour les incidents indirects, tels que l'ajout d'un rôle explicite à un groupe (afin qu'un membre du groupe ait les deux rôles explicites), évaluez si cet utilisateur doit être dans le groupe. Déterminez également si le groupe doit recevoir le rôle explicite, y compris tout héritage par la hiérarchie de groupe et la confinement des rôles.

    Notez que Now Platform rapporte uniquement 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 l'interdépendance utilisateur/groupe/rôle pertinente de façon plus étendue. Vous devrez peut-être repenser la façon dont les groupes et les conteneurs de rôles sont structurés.