L'application utilisateur Identity Manager repose sur un certain nombre de composants indépendants qui agissent ensemble. Les principaux composants, et leurs responsabilités essentielles, sont décrits dans le tableau suivant.
Composant Description
Coffre-fort d'identité (eDirectory 8.7.3 ou 8.8)
Référentiel des données de l'utilisateur (et autres données d'identité) plus l'ensemble des pilotes IDM et les pilotes, ainsi que différents artéfacts de la couche d'abstraction et (si le module de provisioning est installé) des artéfacts de workflow.
(FRA) 27 February 2006
En terme de flux d'informations, les composants qui viennent d'être mentionnés sont liés de façon logique comme l'indique le diagramme ci-dessous. Physiquement, les composants individuels peuvent être (et sont dans la plupart des cas) situés sur plusieurs machines. Par exemple, bien que le coffre-fort d'identité, tout comme son principal outil d'administration, iManager, se trouve
également sur la machine qui héberge le moteur Identity Manager, JBoss (et l'application utilisateur) Moteur Identity Manager Il s'agit de la structure d'exécution Identity Manager qui surveille les
événements dans eDirectory (et les systèmes connectés), appliquant les règles et acheminant les données vers et depuis le coffre-fort d'identité.
Pilote d'application utilisateur Le pilote d'application utilisateur communique avec l'application utilisateur pour laisser cette dernière rafraîchir son cache lorsque les définitions de la couche d'abstraction ont changé. Lorsque le module de provisioning est installé, le pilote d'application utilisateur peut également être configuré pour permettre que des événements du coffre-fort d'identité déclenchent des workflows. Il communique également les informations concernant les droits vers le coffre-fort d'identité, de sorte qu'il existe un enregistrement du droit ayant été accordé (ou non) lorsque le workflow est terminé.
Application utilisateur : interface utilisateur Web
L'interface utilisateur Web de l'application utilisateur est une application java basée sur navigateur à laquelle les portlets compatibles JSR168 se connectent.
Application utilisateur : couche d'abstraction
La couche d'abstraction isole la logique de la couche de présentation du coffre-fort d'identité, de sorte que toutes les requêtes de données d'identité doivent traverser la couche d'abstraction. Le code du portlet ne peut pas obtenir l'accès direct aux informations d'identité. Toutes les requêtes traversent la couche d'abstraction et sont soumises à ses contraintes (sur le contrôle d'accès, par exemple).
Application utilisateur : moteur de flux (disponible uniquement avec le module de provisioning)
Le moteur de flux est un ensemble d'exécutables Java en charge de gérer et d'exécuter les étapes d'un workflow défini par
l'administrateur.
Serveur d'applications JBoss Le serveur d'applications JBoss Open Source fournit la structure d'exécution dans laquelle l'application utilisateur, la couche d'abstraction et le moteur de flux s'exécutent.
Base de données (MySQL par défaut)
La base de données (reportez-vous au Guide d'installation pour connaître la liste des bases de données prises en charge) stocke certains types d'informations de configuration pour le compte de l'application utilisateur, ainsi que l'état du workflow (si le module de provisioning est installé).
Pilote du service Composer Le pilote du service Composer est une partie du pilote d'application utilisateur qui peut être configurée selon les besoins pour répondre aux événements du coffre-fort d'identité en déclenchant des workflows.
Novell Audit Novell Audit est un serveur de consignation indépendant qui peut conserver une variété de types de données (telles que celles générées par les étapes d'un workflow). Pour plus d'informations, reportez-vous au chapitre consacré à la configuration de la consignation, plus loin dans ce document.
Composant Description
(FRA) 27 February 2006 est généralement hébergé sur une machine séparée ou syr un groupe de machines, si elles
fonctionnent en grappes. De même, pour des raisons non seulement de performances, mais également de sécurité et de récupération après sinistre, la base de données (MySQL) se trouve généralement sur sa propre machine.
1.3.1 Coffre-fort d'identité
Le coffre-fort d'identité sert à stocker les données d'identité et les définitions de la couche d'abstraction de diverses sortes. Une instance d'eDirectory (exécutée sous Windows, Solaris ou Linux) est utilisée à cette fin. En utilisant eDirectory, Identity Manager est capable d'exploiter un annuaire LDAPv3 éprouvé, massivement évolutif, de classe entreprise, avec des fonctions de partitionnement et de réplication, ainsi qu'un outil de gestion et de configuration souple basé sur le Web (iManager) qui offre un point d'intégration administratif entre Identity Manager et eDirectory lui-même.
1.3.2 JBoss
L'application utilisateur est fournie comme une archive d'application Web Java, ou fichier WAR. Le WAR est déployé dans JBoss, le serveur d'applications Java Open Source bien connu (qui utilise
(FRA) 27 February 2006 Tomcat comme moteur de servlet ; il n'est pas illustré dans le diagramme). L'utilisation de JBoss
comme environnement d'exécution apporte un grand nombre d'avantages, dont :
• Le code source est disponible gratuitement.
• Depuis la version 4.0.3, JBoss peut fonctionner en grappes.
• JBoss est entièrement compatible J2EE, ce qui signifie que toute application J2EE peut être exécutée dessus. Vous pouvez héberger des applications supplémentaires (par exemple, des services Web) sur la même instance de JBoss que celle de l'application utilisateur.
• JBoss prend en charge les services de sécurité et d'autorisation Java standard JAAS et JACC (sur lesquels repose l'application utilisateur pour l'accès du coffre-fort d'identité).
• JBoss s'exécute sur un grand nombre de plates-formes différentes, notamment les versions courantes de Windows et de Linux.
Le WAR de l'application utilisateur contient le code exécutable de l'application utilisateur, qui est générée à partir d'une architecture MVC (Model-View-Controller), pour la séparation des
préoccupations. Les interfaces exposées à l'utilisateur s'exécutent comme des portlets modulaires au sein de l'application utilisateur. Il existe des portlets distincts pour afficher les organigrammes, effectuer des recherches, afficher les détails de l'utilisateur, réinitialiser les mots de passe, etc.
Pour plus d'informations sur les différents aspects du déploiement d'applications Web sur JBoss, reportez-vous à la documentation de JBoss à l'adresse http://www.jboss.org/products/jbossas/docs (http://www.jboss.org/products/jbossas/docs).
1.3.3 Base de données
L'application utilisateur repose sur une base de données (MySQL par défaut ; reportez-vous au Guide d'installation pour connaître la liste des bases de données prises en charge) pour stocker plusieurs types d'informations :
• Données de configuration de l'application utilisateur : par exemple, définitions de pages Web, enregistrements d'instances de portlet et valeurs de préférence.
• Si le module de provisioning est installé, les informations d'état du workflow sont conservées dans la base de données. Les définitions de workflow réelles sont stockées dans le coffre-fort d'identité.
• Journaux Novell Audit
1.3.4 Moteur Identity Manager
Le produit Identity Manager est constitué d'un moteur d'exécution, de pilotes et de règles. Le moteur Identity Manager répond aux événements dans le coffre-fort d'identité et gère les flux et la
transformation des données à destination et à partir du coffre-fort. Les objets Pilote encapsulent le code exécutable et les artéfacts (tels que les documents des règles) conçus pour fournir les
comportements de gestion des données spécifiques à un système connecté particulier. L'application utilisateur Identity Manager est un système connecté. La communication entre le coffre-fort d'identité, la couche d'abstraction de l'application utilisateur et le moteur de flux s'effectue via le pilote d'application utilisateur (reportez-vous à la description ci-dessous).
Du fait que l'application utilisateur repose sur différents objets d'annuaire pour le stockage des artéfacts de la couche d'abstraction, il est nécessaire d'étendre le schéma eDirectory pour s'adapter aux objets et attributs LDAP personnalisés requis par l'application utilisateur. L'extension du schéma
(FRA) 27 February 2006 se produit automatiquement dans le cadre du processus d'installation Identity Manager. Toutefois, le
remplissage des objets et attributs personnalisés par des valeurs par défaut ne se produit pas tant que le pilote d'application utilisateur n'a pas été installé et n'est pas activé.
1.3.5 Pilote d'application utilisateur
Le pilote d'application utilisateur est un élément d'activation important de l'application utilisateur.
L'une des responsabilités du pilote d'application utilisateur est de notifier la couche d'abstraction lorsque des valeurs de données importantes changent dans le coffre-fort d'identité, afin qu'elle sache qu'elle doit mettre à jour son cache.
Lorsque le module de provisioning est installé, le pilote d'application utilisateur peut être configuré pour déclencher des workflows automatiquement en réponse aux changements des valeurs d'attribut dans le coffre-fort d'identité.
Le pilote d'application utilisateur est non seulement un composant d'exécution, mais également un wrapper de stockage pour les objets d'annuaire (comprenant les artéfacts d'exécution de l'application utilisateur). Une représentation classique des artéfacts d'annuaire associés au pilote d'application utilisateur est illustrée ci-dessous.
Remarque :Les noms illustrés représentent des valeurs de nom commun LDAP. Le nommage du schéma des différentes classes d'objets est abordé ailleurs.
Ces catégories d'artéfact sont abordées plus en détail par la suite.
Objet d'ensemble de pilotes
Chaque installation Identity Manager nécessite le regroupement des pilotes dans des ensembles. Un seul ensemble de pilotes peut être actif à un moment donné (sur un serveur d'annuaire donné). Les pilotes de cet ensemble peuvent être individuellement activés ou désactivés sans incidence sur
(FRA) 27 February 2006 l'ensemble. Le pilote d'application utilisateur (tout comme n'importe quel autre pilote IDM) doit
exister à l'intérieur d'un ensemble de pilotes. L'ensemble de pilotes n'est pas créé automatiquement par l'application utilisateur ; vous devez en créer un à l'avance, puis créer le pilote d'application utilisateur au sein de celui-ci.
Pilote d'application utilisateur
L'objet Pilote d'application utilisateur (qui peut recevoir un nom arbitraire) est le conteneur d'une variété d'artéfacts. Comme avec tous les pilotes Identity Manager, le pilote d'application utilisateur implémente les objets et les règles des canaux Éditeur et Abonné. Le canal Éditeur n'est pas utilisé par l'application utilisateur, bien qu'il soit disponible pour certains cas d'utilisation précis.
Objet AppConfig
L'objet AppConfig est un conteneur pour différents objets de configuration de l'application utilisateur :
RequestDefs
Il s'agit d'un conteneur pour la définition des requêtes de provisioning, les définitions des demandes configurées par l'administrateur utilisables pour l'exécution de l'application utilisateur (si le module de provisioning est installé). Les définitions stockées ici (en XML) représentent les classes de demandes que l'utilisateur final disposant des droits appropriés peut instancier via l'application utilisateur. La définition des demandes associe une définition de flux (ci-dessous) à une définition de ressources.
WorkFlowDefs
Un conteneur des objets de workflow, incluant les descriptions au moment de la conception avec les modèles ou les flux non utilisés.
ResourceDefs
Un conteneur des définitions de ressources provisionnées, incluant les descriptions au moment de la conception avec les modèles ou les cibles non utilisés.
ServiceDefs
Un conteneur des objets de définition de services, qui enveloppent les services Web appelés par des workflows.
DirectoryModel
Les objets de méta-niveau de la couche d'abstraction (ChoiceDefs, EntityDefs, RelationshipDefs), qui représentent différents types de contenu (certains définis par l'utilisateur, d'autres définis par l'administrateur) de l'annuaire qui peuvent être exposés par les portlets d'identité.
AppDefs
Un conteneur des objets de configuration utilisés pour initialiser l'environnement d'exécution, tels que les informations de configuration du cache et les propriétés de notification par message électronique.
(FRA) 27 February 2006
Les portlets reçoivent leurs données d'identité via des requêtes dans la couche d'abstraction de l'annuaire, qui est une couche de code qui isole les détails de l'accès des données d'identité des processus du client. Lorsqu'un portlet doit effectuer une recherche sur des données d'identité, par exemple, la couche d'abstraction effectue les requêtes LDAP appropriées par rapport au conteneur cible dans le coffre-fort d'identité, pour le compte du portlet. À aucun moment un portlet n'effectue de requête directe dans le coffre-fort d'identité.
La couche d'abstraction est également la couche de code par l'intermédiaire de laquelle sont créées ou modifiées les définitions de la couche d'abstraction, telles qu'elles ont été spécifiées par les administrateurs ou d'autres utilisateurs qualifiés du système. Pour effectuer de telles modifications, l'expert du système utilise l'éditeur de couche d'abstraction de l'annuaire du module Designer, décrit plus loin dans ce guide au Chapitre 4, « Configuration de la couche d'abstraction de l'annuaire », page 75.
Lors de l'exécution, la couche d'abstraction cache une grande variété de données de configuration et de définition d'entité obtenues à partir du coffre-fort d'identité. Les différents caches conservés par l'application utilisateur peuvent être gérés de façon détaillée par l'administrateur. Des informations complémentaires sur les caches et la gestion des caches sont disponibles au Chapitre 13,
« Configuration de la mise en cache », page 217.
1.3.7 Moteur de flux
Le moteur de flux (disponible avec le module de provisioning) est l'ensemble des classes d'exécution en charge de l'exécution des étapes d'un workflow spécifiées dans la définition d'un processus (un artéfact d'exécution créé lorsqu'un workflow est instancié) et de la conservation de la trace des informations d'état dans une base de données telle que MySQL ou Oracle. Pour plus d'informations, reportez-vous à la Section 1.3.3, « Base de données », page 24, ci-dessus.
Vous trouverez plus de détails concernant le système de workflow, notamment sur la création des workflows, au Chapitre 21, « Introduction au provisioning basé sur le workflow », page 307, plus loin dans ce guide.
1.3.8 Interface utilisateur
L'interface utilisateur Identity Manager est composée d'un ensemble de portlets compatibles JSR168 (et dans le cas du module de provisioning, de certaines pages de serveur Java) qui s'exécutent au sein d'une application Web Java sur JBoss. L'architecture de portlet offre un haut degré de modularité, de personnalisation de contenu et de contrôle de l'utilisateur sur l'apparence des pages. La structure de l'application utilisateur offre des services de conteneur de différentes sortes. Elle gère l'état des fenêtres, les préférences de portlet, la persistance, la mise en cache, la gestion des thèmes, la consignation, etc., et agit comme gardien de la sécurité. Le serveur d'applications sur lequel s'exécute l'application utilisateur offre à son tour différents services à l'application dans son
(FRA) 27 February 2006 ensemble, notamment l'évolutivité par la mise en grappe, l'accès à la base de données via JDBC et la
prise en charge de la sécurité à base de certificats.
Le degré élevé d'encapsulation permis par cette architecture offre un environnement du niveau présentation robuste et sécurisé pour l'application utilisateur Identity Manager. Elle permet également un degré élevé de contrôle administratif sur tous les aspects de l'interface utilisateur.
Pour plus d'informations concernant l'administration des différents éléments de l'interface
utilisateur, reportez-vous aux chapitres de ce guide sous Partie III, « Administration de l'application utilisateur », page 129.