14.1 À propos de l'onglet Rôles

L'objectif de l'onglet Rôles est de vous offrir un moyen pratique d'effectuer des opérations de provisioning basé sur les rôles. Ces opérations permettent de gérer les définitions et les assignations de rôle au sein de votre entreprise. Les assignations de rôle peuvent être mappées aux ressources d'une entreprise (comptes utilisateur, ordinateurs, bases de données). Par exemple, dans l'onglet Rôles :

Lorsqu'une requête d'assignation de rôle requiert l'autorisation d'une ou de plusieurs personnes au sein d'une entreprise, cette requête lance un workflow. Ce workflow coordonne les approbations nécessaires pour exécuter la requête. Certaines requêtes d'assignation de rôle nécessitent l'approbation d'une seule personne ; d'autres nécessitent l'approbation de plusieurs personnes. Dans certains cas, une requête peut même être effectuée sans aucune approbation.

Si une requête d'assignation de rôle donne lieu à un conflit SoD potentiel, l'initiateur peut annuler la contrainte SoD et fournir une justification pour prouver la nécessité de créer une exception de contrainte. Dans certains cas, un conflit SoD peut entraîner le démarrage d'un workflow. Le workflow coordonne les approbations nécessaires à l'entrée en vigueur de l'exception SoD.

Votre concepteur de workflow et votre administrateur système sont responsables de la définition du contenu de l'onglet Rôles pour vous et les autres utilisateurs de votre entreprise. Le flux de contrôle pour un workflow basé sur les rôles ou un workflow de SoD peut varier, ainsi que l'apparence des formulaires associés, en fonction de la façon dont la définition de l'approbation a été établie dans le concepteur d'Identity Manager. En outre, ce que vous voyiez et ce que vous pouvez faire est généralement déterminé par les exigences de votre fonction et par votre niveau d'autorité.

Le mode proxy est uniquement opérationnel dans l'onglet Requêtes et approbations. Il n'est pas pris en charge dans l'onglet Rôles. Si vous utilisez le mode proxy dans l'onglet Requêtes et approbations, puis passez à l'onglet Rôles, le mode proxy est désactivé pour les deux onglets.

14.1.1 À propos des rôles

Cette section présente les termes et les concepts utilisés dans l'onglet Rôles :

Rôles et assignations de rôle

Un rôle définit un ensemble d'autorisations liées à un ou plusieurs systèmes cibles ou applications. L'onglet Rôles permet aux utilisateurs de faire des requêtes d'assignation de rôle, c'est-à-dire des associations entre un rôle et un utilisateur, un groupe ou un conteneur. L'onglet Rôles permet également de définir des relations de rôle , qui établissent des associations entre les rôles dans la hiérarchie de rôles.

Vous pouvez assigner des rôles directement à un utilisateur. Dans ce cas, ces assignations directes lui confèrent un accès explicite aux autorisations liées à un rôle. Vous pouvez également définir des assignations indirectes, qui permettent aux utilisateurs d'acquérir des rôles grâce à leur appartenance à un groupe, un conteneur ou un rôle associé dans la hiérarchie de rôles.

Lorsque vous effectuez une requête d'assignation de rôle, vous pouvez définir une date d'entrée en vigueur pour indiquer la date et l'heure d'entrée en vigueur de l'assignation. Si vous ne précisez aucune date, l'assignation est immédiate.

Vous pouvez également définir une date d'expiration pour indiquer la date et l'heure de suppression automatique de cette assignation.

Lorsqu'un utilisateur effectue une requête d'assignation de rôle, le sous-système de rôles gère le cycle de vie de la requête de rôle. Pour connaître les opérations qui ont été exécutées au niveau de la requête, vous pouvez vérifier l'état de la requête sur la page Afficher l'état de la requête.

Catalogue et hiérarchie de rôles

Avant que les utilisateurs puissent commencer à assigner des rôles, il faut tout d'abord définir les rôles dans le catalogue de rôles. Le catalogue de rôles est la zone de stockage pour toutes les définitions de rôle. Il prend en charge les données nécessaires au sous-système de rôles. Pour configurer le catalogue de rôles, un administrateur de modules de rôles ou un gestionnaire de rôles définit les rôles et leur hiérarchie.

La hiérarchie de rôles établit des relations entre les rôles du catalogue. Définissez les relations de rôle pour accorder plus facilement les autorisations par le biais des assignations de rôle. Par exemple, au lieu d'assigner 50 rôles médicaux distincts chaque fois qu'un docteur rejoint votre équipe, vous pouvez définir un rôle Docteur et spécifier une relation de rôle entre ce rôle et chacun des rôles médicaux. Assignez des utilisateurs au rôle Docteur pour leur octroyer les autorisations définies pour chaque rôle médical associé.

La hiérarchie de rôles prend en charge trois niveaux. Les rôles définis au plus haut niveau (les rôles métier) déterminent les opérations ayant une signification commerciale au sein de l'organisation. Les rôles définis au niveau intermédiaire (les rôles IT) prennent en charge les fonctions technologiques. Les rôles définis au plus bas niveau (les rôles d'autorisation) déterminent les privilèges de niveau inférieur. Vous trouverez ci-dessous un exemple de hiérarchie de rôles à trois niveaux pour une organisation médicale. Le plus haut niveau de la hiérarchie se situe à gauche et le plus bas à droite :

Figure 14-1 Exemple de hiérarchie de rôles

Un rôle de niveau supérieur comporte automatiquement les privilèges des rôles de niveau inférieur qu'il contient. Un rôle métier, par exemple, comporte automatiquement les privilèges des rôles IT qu'il contient. De même, un rôle IT comporte automatiquement les privilèges des rôles d'autorisation qu'il contient.

Les relations de rôle ne sont pas autorisées entre les rôles homologues au sein de la hiérarchie. De plus, les rôles de niveau inférieur ne peuvent contenir des rôles de niveau supérieur.

Lorsque vous définissez un rôle, vous pouvez éventuellement désigner un ou plusieurs propriétaires pour ce rôle. Un propriétaire de rôle est un utilisateur désigné comme le propriétaire de la définition de rôle. Si vous générez des rapports par rapport au catalogue de rôles, vous pouvez filtrer ces rapports en fonction du propriétaire de rôle. Le propriétaire d'un rôle n'a pas nécessairement l'autorisation d'apporter des modifications à la définition d'un rôle. Dans certains cas, le propriétaire doit demander à un administrateur de rôles de réaliser les opérations d'administration sur ce rôle.

Lorsque vous définissez un rôle, vous pouvez éventuellement associer le rôle à une ou plusieurs catégories de rôle. Une catégorie de rôle permet de classer les rôles par catégorie afin d'organiser le système de rôles. Une fois qu'un rôle a été associé à une catégorie, vous pouvez utiliser cette catégorie comme filtre lorsque vous affichez le catalogue de rôles.

Si une requête d'assignation de rôle nécessite une approbation, la définition de rôle fournit des détails sur le processus de workflow utilisé pour coordonner les approbations, ainsi que la liste des approbateurs. Les approbateurs sont les personnes qui ont le pouvoir d'approuver ou de rejeter une requête d'assignation de rôle.

Séparation des tâches (SoD)

La capacité à définir des contraintes SoD est une des caractéristiques clés du sous-système de rôles. Une contrainte SoD est une règle qui définit deux rôles jugés en conflit. Les responsables de la sécurité créent les contraintes SoD pour une organisation. Grâce aux contraintes SoD, ces responsables peuvent empêcher les utilisateurs d'être assignés à des rôles en conflit. Ils peuvent également tenir un suivi d'audit pour conserver une trace des cas où des violations ont été autorisées. Dans une contrainte SoD, les rôles en conflit doivent appartenir au même niveau de la hiérarchie de rôles.

Certaines contraintes SoD peuvent être remplacées sans approbation ; d'autres en nécessitent une. Les conflits autorisés sans approbation sont des violations SoD. Les conflits approuvés sont des exceptions SoD approuvées. Le sous-système de rôles ne nécessite pas d'approbation pour les violations SoD issues d'assignations indirectes (appartenance à un groupe ou à un conteneur ou relations de rôle).

Si un conflit SoD nécessite une approbation, la définition de contrainte fournit des détails sur le processus de workflow utilisé pour coordonner les approbations, ainsi que la liste des approbateurs. Les approbateurs sont les personnes qui ont le pouvoir d'approuver ou de rejeter une exception SoD. Une liste par défaut est définie dans le cadre de la configuration du sous-système de rôles. Cette liste peut cependant être remplacée dans la définition d'une contrainte SoD.

Rôles : audit et création de rapport

Le sous-système de rôles constitue une riche fonctionnalité de création de rapport. Il permet aux auditeurs d'analyser le catalogue de rôles, ainsi que l'état des assignations de rôle et des contraintes, violations et exceptions SoD. La fonctionnalité de création de rapport sur les rôles permet aux auditeurs de rôles et aux administrateurs de modules de rôles d'afficher les types de rapports suivants au format PDF :

  • Rapport de listes de rôles

  • Rapport de détails de rôle

  • Rapport d'assignations de rôle

  • Rapport de contrainte de SoD

  • Rapport de violations et d'exceptions SoD

  • Rapport des rôles de l'utilisateur

  • Rapport des droits utilisateur

Le sous-système de rôles fournit des informations grâce à la fonctionnalité de création de rapport. Il peut en outre être configuré pour consigner les événements dans Novell® Audit.

Sécurité des rôles

Le sous-système de rôles fait appel à un ensemble de rôles système pour accéder en toute sécurité aux fonctions de l'onglet Rôles. Chaque opération de menu dans l'onglet Rôles est assignée à un ou plusieurs rôles système. Si un utilisateur n'est pas membre d'un des rôles associés à l'opération, l'élément de menu correspondant ne s'affiche pas dans l'onglet Rôles.

Les rôles système sont des rôles d'administration définis par le système lors de l'installation à des fins de délégation des tâches administratives. Ce sont notamment les modifications suivantes :

  • Administrateur de modules de rôles

  • Gestionnaire de rôles

  • Auditeur de rôles

  • Responsable de sécurité

Les rôles système sont décrits en détail ci-dessous :

Tableau 14-1 Rôles système

Rôle

Description

Administrateur de modules de rôles

Ce rôle système permet aux membres de créer, de supprimer ou de modifier l'ensemble des rôles, ainsi que d'accorder ou de révoquer les assignations de rôle des utilisateurs, des groupes ou des conteneurs. Il permet également d'exécuter n'importe quel rapport pour tous les utilisateurs quels qu'ils soient. Une personne assignée à ce rôle peut effectuer sans restriction les opérations suivantes dans l'application utilisateur :

  • Créer, supprimer et modifier les rôles.

  • Modifier les relations de rôle pour les rôles.

  • Faire des requêtes d'assignation d'utilisateurs, de groupes ou de conteneurs à des rôles.

  • Créer, supprimer et modifier les contraintes SoD.

  • Consulter le catalogue de rôles.

  • Configurer le sous-système de rôles.

  • Afficher l'état de toutes les requêtes.

  • Retirer des requêtes d'assignation de rôle.

  • Exécuter un ou tous les rapports.

Gestionnaire de rôles

Ce rôle système permet aux membres de modifier les rôles et les relations de rôle. Il permet également d'accorder ou de révoquer des assignations de rôle pour les utilisateurs. Une personne assignée à ce rôle peut effectuer les opérations suivantes dans l'application utilisateur mais est limitée par les droits Parcourir des répertoires associés aux objets de rôle :

  • Créer de nouveaux rôles et modifier les rôles existants pour lesquels l'utilisateur possède des droits Parcourir.

  • Modifier les relations de rôle concernant les rôles pour lesquels l'utilisateur possède des droits Parcourir.

  • Faire des requêtes d'assignations d'utilisateurs, de groupes ou de conteneurs à des rôles pour lesquels l'utilisateur a des droits Parcourir.

  • Parcourir le catalogue de rôles (limité en raison des droits Parcourir).

  • Parcourir les requêtes d'assignations de rôle pour les utilisateurs, les groupes et les conteneurs (limité en raison des droits Parcourir des répertoires associés aux objets de rôle, d'utilisateur, de groupe et de conteneur).

  • Retirer les requêtes d'assignations de rôle pour les utilisateurs, les groupes et les conteneurs (limité en raison des droits Parcourir des répertoires associés aux objets de rôle, d'utilisateur, de groupe et de conteneur).

Auditeur de rôles

Ce rôle système permet aux membres d'exécuter des rapports pour lesquels ils possèdent des droits Parcourir des répertoires.

Responsable de sécurité

Ce rôle système permet aux membres de créer, de supprimer ou de modifier les contraintes SoD. Le responsable de sécurité doit posséder des droits Parcourir associés aux contraintes SoD.
Utilisateur authentifié

Outre la prise en charge des rôles système, le sous-système de rôles permet l'accès par les utilisateurs authentifiés. Un utilisateur authentifié est un utilisateur logué à l'application utilisateur qui ne dispose pas de privilèges spéciaux grâce à l'appartenance à un rôle système. Un utilisateur authentifié typique peut effectuer toutes les opérations suivantes :

  • Afficher tous les rôles qui ont été assignés à l'utilisateur.

  • Faire une requête d'assignation (uniquement pour son compte) concernant les rôles pour lesquels l'utilisateur possède des droits Parcourir.

  • Afficher l'état de la requête concernant les requêtes pour lesquelles l'utilisateur possède des droits Parcourir.

  • Retirer les requêtes d'assignation de rôle concernant les rôles pour lesquels l'utilisateur est à la fois demandeur et destinataire.

Pilote de services de rôles

Le sous-système de rôles fait appel au pilote de services de rôles pour gérer le traitement final des rôles. Ce pilote a diverses fonctions dont voici quelques exemples : il gère toutes les assignations de rôle ; il lance les workflow pour les requêtes d'assignations de rôle et les conflits nécessitant une approbation ; il consigne les assignations de rôle indirectes en fonction de l'appartenance à un groupe ou conteneur, ainsi que l'appartenance aux rôles associés. Le pilote a également deux autres fonctions : accorder et retirer les droits utilisateur en fonction de l'appartenance à un rôle, mais aussi réaliser des procédures de nettoyage pour les requêtes qui ont été menées à bien.

Pour plus de détails sur le pilote de services de rôles, reportez-vous au Guide d'administration de l'application utilisateur Identity Manager.