Novell Identity Manager est un logiciel système qui permet à votre entreprise de gérer en toute sécurité les besoins d'accès de sa communauté d'utilisateurs. Si vous êtes membre de cette communauté d'utilisateurs, vous bénéficiez Identity Manager de plusieurs manières. Par exemple, Identity Manager permet à votre entreprise :
D'offrir aux utilisateurs l'accès aux informations (recherche d'organigrammes de groupe, de pages blanches du service ou d'employés) ainsi qu'aux rôles et aux ressources (équipements ou comptes sur les systèmes internes) dont ils ont besoin, dès le départ
De synchroniser plusieurs mots de passe dans un seul login pour tous les systèmes
De modifier ou révoquer des droits d'accès de façon instantanée si nécessaire (par exemple lorsqu'une personne est transférée dans un groupe différent ou quitte l'entreprise)
De respecter la conformité vis-à-vis des réglementations gouvernementales
Pour vous apporter directement ces avantages, à vous et à votre équipe, l'application utilisateur Identity Manager est dotée d'une interface utilisateur à laquelle vous pouvez accéder depuis votre navigateur Web.
L'application utilisateur Identity Manager constitue votre fenêtre sur les informations, les rôles, les ressources et les fonctionnalités d'Identity Manager. Votre administrateur système détermine les détails de ce que vous pouvez afficher et faire dans l'application utilisateur Identity Manager. En général, il s'agit des éléments suivants.
Self-service d'identité, qui permet :
D'afficher des organigrammes
De générer des rapports d'applications associés à un utilisateur si vous êtes administrateur (Le module de provisioning basé sur les rôles Identity Manager est requis.)
De modifier les informations de votre profil
D'effectuer une recherche dans un répertoire
De modifier le mot de passe, la stimulation-réponse de mot de passe et l'indice de mot de passe
De consulter l'état de votre stratégie de mot de passe et l'état de synchronisation du mot de passe
De créer des comptes pour les utilisateurs ou les groupes nouveaux (si vous y êtes autorisé)
Rôles, qui permettent :
De faire des requêtes d'assignation de rôle et gérer le processus d'approbation associé
De vérifier l'état de vos requêtes de rôle
De définir les rôles et les relations de rôle
De définir les contraintes SoD et gérer le processus d'approbation en cas de requête d'annulation de contrainte faite par un utilisateur
De parcourir le catalogue de rôles
D'afficher les rapports détaillés répertoriant les rôles et les contraintes SoD définis dans le catalogue, ainsi que l'état des assignations de rôle, les exceptions SoD et les droits des utilisateurs
Ressources, qui permettent :
De formuler des requêtes d'assignation de ressource et gérer le processus d'approbation associé
De vérifier l'état de vos requêtes de ressource
De parcourir le catalogue de ressources
Processus de workflow, qui permettent :
De demander des processus de workflow personnalisés
De vérifier l'approbation de vos requêtes de rôle, de ressource et de processus
De travailler aux tâches qui vous sont assignées pour approuver d'autres requêtes
D'effectuer des requêtes et des approbations de processus en tant que proxy ou délégué pour un autre utilisateur
D'assigner un autre utilisateur devant être votre proxy ou votre délégué (si vous y êtes autorisé)
De gérer toutes ces fonctions de requête et d'approbation pour votre équipe (si vous y êtes autorisé)
Conformité, qui permet :
De demander un processus d'attestation de profil utilisateur
De demander un processus d'attestation de violation de séparation des tâches (SoD, Separation of Duties)
De demander un processus d'attestation d'assignation de rôle
De demander un processus d'attestation d'assignation utilisateur
Figure 1-1 L'application utilisateur IDM fournit l'interface utilisateur Identity Manager
Voici quelques exemples d'utilisation classique de l'application utilisateur Identity Manager au sein d'une entreprise.
Ella (une utilisatrice finale) récupère son mot de passe oublié par l'intermédiaire des fonctions du self-service d'identité lorsqu'elle se logue.
Erik (un utilisateur final) recherche tous les employés parlant l'allemand sur son lieu de travail.
Eduardo (un utilisateur final) navigue dans l'organigramme, trouve Ella, puis clique sur une icône représentant une enveloppe pour lui envoyer un message.
Maxine (gestionnaire de rôles) crée les rôles métier Infirmière et Docteur, ainsi que les rôles IT Administration de médicaments et Délivrance d'ordonnances. Maxine crée plusieurs ressources nécessaires à ces rôles et les associe à ces derniers.
Maxine (un gestionnaire de rôles) définit une relation entre les rôles Infirmière et Administration de médicaments en spécifiant que le premier rôle inclut le deuxième. Max définit également une relation entre les rôles Docteur et Délivrance d'ordonnances en spécifiant que le premier rôle inclut le deuxième.
Chester (un responsable de la sécurité) définit une contrainte SoD qui spécifie la présence d'un conflit potentiel entre les rôles Docteur et Infirmière. Cela signifie qu'un utilisateur donné ne peut pas être assigné aux deux rôles à la fois. Dans certains cas, un utilisateur qui fait une requête d'assignation de rôle peut souhaiter annuler cette contrainte. Pour définir une exception SoD, l'utilisateur qui demande l'assignation doit donner une justification.
Ernest (un utilisateur final) parcourt une liste de rôles à sa disposition et fait une requête d'assignation pour le rôle d'infirmière.
Amy (une approbatrice) reçoit une notification de requête d'approbation par courrier électronique (avec un lien URL). Elle clique sur le lien, voit s'afficher un formulaire d'approbation, puis l'approuve.
Arnold (un gestionnaire de rôles) demande que le rôle Docteur soit assigné à Ernest. Il reçoit une notification l'informant qu'un conflit potentiel existe entre le rôle Docteur et le rôle Infirmière, auquel Ernest a déjà été assigné. Il fournit une justification pour prouver la nécessité de faire une exception de contrainte SoD.
Edward (un approbateur SoD) reçoit une notification de conflit SoD par courrier électronique. Il approuve la demande d'Arnold concernant l'annulation de la contrainte SoD.
Amélia (une approbatrice) reçoit une notification de requête d'approbation pour le rôle Docteur par courrier électronique. Elle approuve la requête d'Arnold concernant l'assignation d'Ernest au rôle Docteur.
Bill (auditeur de rôles) vérifie le rapport des violations et des exceptions SoD et remarque qu'Ernest a été assigné à la fois au rôle Docteur et au rôle Infirmière. De plus, il constate qu'Ernest a été assigné aux ressources associées à ces rôles.
Ernie (un utilisateur final) parcourt la liste des ressources qui sont à sa disposition et demande l'accès au système Siebel*.
Amy (une approbatrice) reçoit la notification d'une requête d'approbation par courrier électronique (contenant une URL). Elle clique sur le lien, voit s'afficher un formulaire d'approbation, et l'approuve.
Ernie vérifie l'état de sa requête précédente concernant l'accès à Siebel (qui est passée à une seconde personne pour approbation). Il voit qu'elle est toujours en cours de traitement.
Amy part en vacances et indique qu'elle sera temporairement indisponible. À présent, les nouvelles tâches d'approbation lui sont assignées pendant son absence.
Amy ouvre sa liste de tâches d'approbation, voit qu'elle en contient trop pour qu'elle puisse y répondre à temps et en réassigne plusieurs à des collaborateurs.
Patricia (une assistante administrative) agit en tant qu'utilisateur proxy pour Amy et ouvre la liste de tâches de cette dernière afin d'effectuer une tâche d'approbation pour son compte.
Max (un gestionnaire) consulte les listes de tâches des employés de son service. Il sait qu'Amy est en vacances et réassigne ses tâches aux autres personnes du service.
Max effectue une requête pour un compte de base de données d'une personne de son service qui travaille sous son autorité directe.
Max assigne Dan en tant que délégué autorisé pour Amy.
Dan (désormais approbateur délégué) reçoit les tâches d'Amy lorsqu'elle n'est pas disponible.
Max engage un stagiaire non rémunéré, qui ne doit pas figurer dans le système des RH. L'administrateur système crée l'enregistrement de l'utilisateur pour ce stagiaire et demande que lui soit accordé l'accès à Notes, Active Directory* et Oracle*.
Maxine (un gestionnaire de rôles) crée les rôles métier Infirmière et Docteur, ainsi que les rôles IT Administration de médicaments et Délivrance d'ordonnances.
Maxine (un gestionnaire de rôles) définit une relation entre les rôles Infirmière et Administration de médicaments en spécifiant que le premier rôle inclut le deuxième. Max définit également une relation entre les rôles Docteur et Délivrance d'ordonnances en spécifiant que le premier rôle inclut le deuxième.
Chester (un responsable de la sécurité) définit une contrainte SoD qui spécifie la présence d'un conflit potentiel entre les rôles Docteur et Infirmière. Cela signifie qu'un utilisateur donné ne peut pas être assigné aux deux rôles à la fois. Dans certains cas, un utilisateur qui fait une requête d'assignation de rôle peut souhaiter annuler cette contrainte. Pour définir une exception SoD, l'utilisateur qui demande l'assignation doit donner une justification.
Arnold (un gestionnaire de rôles) demande que le rôle Docteur soit assigné à Ernest. Il reçoit une notification l'informant qu'un conflit potentiel existe entre le rôle Docteur et le rôle Infirmière, auquel Ernest a déjà été assigné. Il fournit une justification pour prouver la nécessité de faire une exception de contrainte SoD.
Philippe (administrateur du module Conformité) initie un processus d'attestation d'assignation de rôle pour le rôle Infirmière.
Fiona (chargée d'attestation) reçoit une notification de la tâche d'attestation par courrier électronique (avec un lien URL). Elle clique sur le lien et voit s'afficher un formulaire d'attestation. Elle apporte une réponse affirmative à la question d'attestation, indiquant ainsi que les informations sont correctes.
Philippe (administrateur du module Conformité) initie un nouveau processus de requête d'attestation de profil utilisateur pour les utilisateurs du groupe des ressources humaines.
Chaque utilisateur du groupe des ressources humaines reçoit une notification de la tâche d'attestation par courrier électronique (avec un lien URL). Chaque utilisateur clique sur le lien et voit s'afficher un formulaire d'attestation. Ce formulaire permet à l'utilisateur de vérifier les valeurs des attributs de profil utilisateur. Après avoir vérifié les informations, chaque utilisateur répond à la question d'attestation.