Explicit Roles
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. ServiceNow AI Platform abandonne toute opération qui créerait un tel scénario.
- Tables sans le rôle qui hérite du rôle snc_external ou du rôle public.
- Les ressources de type autre qu’un enregistrement, telles que les processeurs et les pages de l’interface utilisateur, n’accordant pas l’accès au rôle snc_external ou à un rôle qui hérite du rôle snc_external.
- Tableaux de bord Platform Analytics.
Ne marquez pas le rôle snc_internal comme élevé. Sinon, les utilisateurs internes ne pourront pas accéder à l'instance.
Module d'extension Explicit Roles
Lorsque le module d'extension Explicit Roles est activé :
- Tous les Les utilisateurs doivent disposer du rôle snc_internal pour accéder aux ressources internes ou du rôle snc_external pour accéder aux ressources externes. Les utilisateurs sans rôle explicite ne peuvent accéder qu'aux ressources publiques.
- 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.
- 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.
Une fois que le module d'extension est activé, chaque fois qu'un utilisateur se connecte, il reçoit le rôle snc_internal si le compte n'a pas déjà ce rôle ou celui de snc_external. Cela inclut les utilisateurs connectés via l'emprunt d'identité.
- 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 utilisateurs 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 doit être accordé manuellement aux utilisateurs externes. L'accès aux enregistrements est accordé par l'intermédiaire des ACL.
Ne déplacez pas les ensembles de mises à jour système entre les instances avec et sans le module d'extension Explicit Roles activé. Pour plus d'informations, consultez Ensembles de mises à jour système.
Comportement glide.security.explicit_roles.do_not_fix
, le glide.security.explicit_roles.do_not_fix a été ajusté avec des modifications apportées à snc_internal. Le rôle snc_internal est maintenant le même en mémoire et en sys_user_has_role. Le nouveau comportement de glide.security.explicit_roles.do_not_fix est le suivant :| Valeur | Résultat |
|---|---|
| Faux | Ajouter snc_internal rôle en mémoire et en sys_user_has_role |
| Vrai | Ne pas ajouter snc_internal rôle dans la mémoire ou sys_user_has_role |
glide.security.explicit_roles.ignore.snc_internal.exclude_role_list . de glide.security.explicit_roles.do_not_fix, utilisez la propriété glide.security.explicit_roles.do_not_fix_in_memory .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 Provide external users access to a table.
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).
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
- Affectez à l'utilisateur Abel Tuter le rôle snc_internal.
- 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) :
- Considérez un groupe appelé groupe de tests qui n'a actuellement aucun rôle explicite affecté au groupe.
- Ajoutez Abel Tuter au groupe de tests.
- 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.
- Affectez à l'utilisateur Abel Tuter le rôle snc_internal.
- Considérez un groupe appelé groupe de tests qui n'a actuellement aucun rôle explicite affecté au groupe.
- Ajoutez Abel Tuter au groupe de tests.
- 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 |
|
L'action est abandonnée. |
| Confinement de rôle sans collision |
|
Le rôle est ajouté à la fois à l'utilisateur et au rôle de test. |
| Confinement de groupe avec collision |
|
L'action est abandonnée. |
| Confinement de groupe sans collision |
|
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 |
|
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 ServiceNow AI 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.
Demander des rôles explicites
Activez Rôles explicites en demandant le module d’extension Rôles explicites (com.glide.explicit_roles) via Catalogue de Now Support services.
Avant de commencer
Rôle requis : admin