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 et ressources permet aux utilisateurs de formuler 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 et ressources permet également de définir des relations entre rôles, 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 et de ressources 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 par des utilisateurs ou le sous-système, vous pouvez vérifier l'état de la requête sous l'onglet État des requêtes dans le Catalogue de rôles.

Catalogue et hiérarchie de rôles

Avant que les utilisateurs puissent commencer à assigner des rôles, ces derniers doivent d'abord être définis dans le Catalogue de rôles. Le Catalogue de rôles est l'espace de stockage pour toutes les définitions de rôle et les données de prise en charge nécessaires au sous-système de rôles et de ressources. Pour configurer le Catalogue de rôles, un administrateur du module 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 et de ressources. 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 et de ressources ne nécessite pas d'approbation pour les violations SoD issues d'assignations indirectes telles que l'adhésion à un groupe ou à un conteneur ou des relations entre rôles.

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 et de ressources. 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 et de ressources comporte une riche fonctionnalité de création de rapports. Il permet aux auditeurs d'analyser le catalogue de rôles, ainsi que l'état des assignations de rôles 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 du module de rôles d'afficher les types de rapports suivants au format PDF :

Outre la fourniture d'informations via la fonction de création de rapports, le sous-système de rôles et de ressources peut être configuré pour consigner des événements dans les clients d'audit Novell ou OpenXDAS.

Sécurité des rôles

Le sous-système de rôles et de ressources fait appel à un ensemble de rôles système pour accéder en toute sécurité aux fonctions de l'onglet Rôles et ressources. Chaque opération de menu dans l'onglet Rôles et ressources 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 et ressources.

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. Il s'agit notamment des rôles suivants :

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

Pilote de service de rôle et de ressource

Le sous-système de rôles et de ressources fait appel au pilote de service de rôle et de ressource pour gérer les processus de traitement d'interface dorsale applicables aux 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 service de rôle et de ressource, reportez-vous au Guide d'administration de l'application utilisateur Identity Manager.

À propos du provisioning basé sur les ressources

L'objectif de la fonction de ressource dans l'application utilisateur est de vous fournir une méthode pratique pour réaliser des opérations de provisioning basé sur les ressources. Ces opérations permettent de gérer les définitions et les assignations de ressources au sein de votre organisation. Les assignations de ressources peuvent être attribuées à des utilisateurs ou des rôles d'une entreprise. Par exemple, vous pouvez utiliser des ressources pour effectuer les opérations suivantes :

Lorsqu'une requête d'assignation de ressource nécessite l'autorisation d'une ou de plusieurs personnes au sein d'une organisation, 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 ressource nécessitent l'approbation d'une seule personne ; d'autres requièrent l'approbation de plusieurs personnes. Dans certains cas, une requête peut même être effectuée sans aucune approbation.

Le comportement des ressources dans l'application utilisateur est régi par les règles d'entreprise suivantes :

Votre concepteur de workflow et votre administrateur système sont chargés de configurer l'application utilisateur pour vous-même et les autres utilisateurs au sein de votre organisation. Le flux de contrôle d'un workflow basé sur les ressources ainsi que l'apparence des formulaires peuvent varier selon la manière dont la définition d'approbation pour le workflow a été déterminée dans Designer pour Identity Manager. En outre, les écrans affichés et les opérations disponibles sont généralement déterminés par les exigences de votre fonction et par votre niveau d'autorité.

Ressources

Une ressource est une entité numérique, telle qu'un compte utilisateur, un ordinateur ou une base de données, à laquelle un utilisateur doit avoir accès. L'application utilisateur offre aux utilisateurs finaux un moyen pratique de demander les ressources dont ils ont besoin. Elle propose en outre des outils dont les administrateurs peuvent se servir pour définir des ressources.

Chaque ressource est assignée à un droit. Une définition de ressource ne peut être associée qu'à un seul droit. Elle peut en revanche être associée plusieurs fois au même droit, avec des paramètres de droit différents pour chaque ressource.

Requêtes de ressources

Les ressources ne peuvent être assignées qu'à des utilisateurs. Elles ne peuvent pas l'être à des groupes ou des conteneurs. Toutefois, si un rôle est assigné à un groupe ou un conteneur, les utilisateurs de ce groupe ou conteneur peuvent se voir accorder automatiquement les ressources associées au rôle.

Les requêtes de ressources peuvent nécessiter des approbations. Le processus d'approbation pour une ressource peut être géré par une définition de requête de provisioning ou par un système externe en définissant le code d'état sur la requête de ressource.

Si une requête d'accord de ressource est initiée par une assignation de rôle, il se peut que la ressource ne soit pas accordée, même si le rôle est provisionné. La raison la plus probable serait que les approbations nécessaires n'ont pas été fournies.

Une requête de ressource peut accorder une ressource à un utilisateur ou la lui révoquer.

Pilote de service de rôle et de ressource

L'application utilisateur fait appel au pilote du service de rôles et de ressources pour gérer les processus de traitement d'interface dorsale applicables aux ressources. Par exemple, il gère toutes les requêtes de ressource, lance les workflows pour ces dernières et initie également leur processus de provisioning.