Voici quelques exemples d'utilisation classique des applications d'identité au sein d'une entreprise.
Ella (une utilisatrice finale) récupère son mot de passe oublié au moyen des fonctions du libre-service d'identité lorsqu'elle se connecte.
Par défaut, Identity Manager utilise la réinitialisation de mot de passe en self-service (SSPR) pour permettre aux utilisateurs de modifier leur mot de passe. Toutefois, les applications d'identité peuvent utiliser d'autres méthodes pour gérer les mots de passe oubliés. Pour plus d'informations, reportez-vous à la section Configuration de la gestion des mots de passe oubliés du Guide d'installation de NetIQ Identity Manager.
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élie (une approbatrice) reçoit une notification de requête d'approbation pour le rôle de 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.