15.1 À propos de l'onglet Rôles et ressources

L'objectif de l'onglet Rôles et ressources est de vous offrir un moyen pratique d'effectuer des opérations de provisioning basé sur les rôles. Celles-ci vous permettent de gérer les définitions ainsi que les assignations de rôles et de ressources au sein de votre organisation. Les assignations de rôle peuvent être assignées aux ressources d'une entreprise (comptes utilisateur, ordinateurs, bases de données). Il est aussi possible d'assigner des ressources directement à des utilisateurs. Par exemple, vous pouvez utiliser l'onglet Rôles et ressources pour effectuer les opérations suivantes :

Lorsqu'une requête d'assignation de rôle ou 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 rôle 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.

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 configuration du contenu de l'onglet Rôles et ressources pour vous-même et les autres utilisateurs de votre entreprise. Le flux de contrôle d'un workflow 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é.

REMARQUE :l'onglet Rôles et ressources n'est disponible que dans la version Advanced Edition d'Identity Manager 4.0.1. La version Standard Edition ne prend pas en charge cette fonction.

15.1.1 À propos des rôles

Cette section présente un aperçu des termes et concepts utilisés dans l'onglet Rôles et ressources :

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 15-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 :

  • 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

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 :

  • Administrateur de rôles

  • Gestionnaire de rôles

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

Tableau 15-1 Rôles système

Rôle

Description

Administrateur 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 et de ressources.

  • 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 de consultation 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 de consultation.

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

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

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

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

Utilisateur authentifié

Outre la prise en charge des rôles système, le sous-système de rôles et de ressources 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 de consultation.

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

  • 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 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.

Conséquences de la modification des droits assignés à une ressource. Si vous modifiez le droit associé à une ressource existante, le pilote n'accorde pas le nouveau droit aux utilisateurs auxquels la ressource est actuellement assignée. Pour accorder le nouveau droit, vous devez supprimer puis réassigner la ressource aux utilisateurs devant disposer de ce droit.

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.

15.1.2 À propos des ressources

Cette section présente un aperçu des termes et concepts de gestion des ressources utilisés dans l'application utilisateur.

À 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 :

  • Faire des requêtes de ressources pour vous ou d'autres utilisateurs au sein de votre organisation

  • Créer des ressources et les assigner à des droits

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 :

  • Les ressources peuvent uniquement être assignées à un utilisateur. Cela n'empêche toutefois pas l'octroi d'une ressource à des utilisateurs inclus dans un conteneur ou un groupe sur la base d'une assignation de rôle implicite. L'assignation de la ressource sera cependant uniquement associée à un utilisateur.

  • Les ressources peuvent être assignées selon n'importe laquelle des méthodes suivantes :

    • Directement par un utilisateur via des mécanismes d'IU

    • Par le biais d'une requête de provisioning

    • Par le biais d'une assignation de requête de rôle

    • Par le biais d'une interface Rest ou SOAP

  • La même ressource peut être accordée à un utilisateur plusieurs fois (pour autant que cette fonction ait été activée dans la définition de la ressource).

  • Une définition de ressource ne peut être associée qu'à un seul droit.

  • Une définition de ressource peut être associée à une ou plusieurs références d'un même droit. Cela permet de prendre en charge les droits pour lesquels les paramètres du droit représentent des autorisations ou des comptes provisionnables sur le système connecté.

  • Les paramètres de support des droits et décisions peuvent être spécifiés au moment de la conception (statique) ou de la requête (dynamique).

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.