6.13 Règles, stratégies et feuilles de style
Dans Identity Manager, une règle est une collection de stratégies. Chaque règle comporte des conditions à remplir et des opérations à exécuter lorsque les conditions sont remplies. La grammaire des conditions est destinée à être lisible pour un être humain et doit, en général, avoir un sens. Par exemple, la condition « si la classe d'objet est égale à l'utilisateur » est vraie si l'objet décrit dans le document actif est un objet Utilisateur, et fausse si l'objet est un groupe. Les conditions sont constituées de groupes de conditions. Au sein d'un groupe de conditions, toutes les conditions peuvent être associées par « et » ou « ou » et le résultat doit être vrai pour que le groupe de conditions soit évalué comme vrai, faute de quoi il est évalué comme faux. Plusieurs groupes de conditions peuvent aussi être associés, à l'aide de « et » et « ou ». Une fois que le ou les groupes de conditions ont été évalués comme vrais, les opérations de la règle sont exécutées.
Figure 6-2 Conditions du générateur de stratégies
Les opérations peuvent agir sur le document actif, et cela suffit généralement. Les opérations peuvent toutefois aussi interroger la source ou la cible (qui pourrait être le coffre-fort d'identité ou le système connecté, selon le canal sur lequel vous vous trouvez) pour obtenir des informations complémentaires. Des opérations peuvent remplacer le document actif par une version modifiée, ou bien le bloquer dans son intégralité. Des opérations peuvent être utilisées pour fabriquer différents documents. Un document qui décrit un événement de suppression dans un système connecté pourrait être testé par une condition (si l'opération est égale à Supprimer) et subir un ensemble d'opérations visant à empêcher la suppression de l'objet associé dans le coffre-fort d'identité (veto) en le modifiant de manière à supprimer sa valeur d'association pour cette application (supprimer une association) ainsi qu'à le désactiver (définir la valeur de l'attribut cible Login Disabled (Login désactivé) = True (Vrai)).
Figure 6-3 Opérations du générateur de stratégies
Les stratégies définissent quelles données sont transférées et comment elles sont synchronisées entre le système connecté et le coffre-fort d'identité. Un ensemble par défaut de stratégies est disponible avec la configuration du pilote. Les autres stratégies peuvent être des personnalisations locales du pilote. Vous pouvez écrire des stratégies en utilisant le script DirXML, XSLT ou le script ECMA.
Une stratégie a pour objectif d'apporter des modifications au document d'entrée afin de produire un document de sortie. La plupart des stratégies sont évaluées soit sur le canal Abonné, soit sur le canal Éditeur. La stratégie d'assignation de schéma, la stratégie de transformation de l'entrée et la stratégie de transformation de la sortie sont évaluées sur les deux canaux. Par exemple, une organisation peut utiliser inetOrgPerson en tant que classe Utilisateur principale, et une autre société peut employer Utilisateur. Une stratégie peut être implémentée pour ajouter le changement de numéro de téléphone à inetOrgPerson pour la première organisation et une règle distincte peut être implémentée pour que cela fonctionne pour la classe Utilisateur. Les stratégies opèrent des transformations de schéma, spécifient les critères de concordance pour déterminer si un objet existe déjà dans le système connecté ou dans le coffre-fort d'identité et réalisent bien d'autres choses encore. De ce fait, un événement d'ajout signalé par votre système connecté peut devenir une opération de modification dans le coffre-fort d'identité, si une stratégie de concordance détermine que l'objet que vous avez ajouté existe déjà dans le coffre-fort d'identité.
Sur le canal Abonné, lorsqu'un nouvel utilisateur est créé dans le coffre-fort d'identité et que vous souhaitez qu'il soit créé dans le système connecté, avant d'envoyer cette commande au pilote, le moteur Identity Manager appelle une série de stratégies. Ces stratégies définissent la manière dont les objets sont créés et déterminent si un utilisateur correspondant existe déjà dans le système connecté. Elles prennent également des décisions au sujet du placement, fournissent des valeurs par défaut pour les attributs obligatoires non spécifiés, etc. Cet événement d'ajout sera peut-être transformé en événement de modification si l'objet existe dans le système connecté. Les attributs qui n'étaient pas contenus dans l'événement original peuvent être ajoutés afin qu'il soit conforme au modèle de création d'objet du système connecté.
Les feuilles de style définissent les règles de transformation XSLT. Les feuilles de style modifient les commandes d'entrée ou de sortie, changent le type d'un événement ou opèrent d'autres transformations XML arbitraires. Pour plus d'informations, reportez-vous au Identity Manager Style Sheets (Feuilles de style Identity Manager).
6.13.1 Règle de transformation de l'entrée
La règle de transformation de l'entrée s'applique à la fois au canal Abonné et au canal Éditeur. La règle de transformation de l'entrée a pour objectif d'effectuer une transformation préliminaire sur tous les documents XML envoyés et renvoyés à Identity Manager par le système connecté. La règle de transformation de l'entrée est appliquée aux documents XML envoyés aux commandes XmlCommandProcessor.execute et XmlQueryProcessor.query lorsqu'ils sont appelés par le système connecté et aux documents XML renvoyés par les commandes SubscriptionShim.execute et XmlQueryProcessor.query lorsqu'ils sont invoqués par le moteur Identity Manager. La stratégie de transformation de l'entrée est appliquée avant celle d'assignation de schéma.
La règle de transformation de l'entrée sert souvent à convertir des données du format de l'application au format du coffre-fort d'identité. Lorsque la stratégie de transformation de l'entrée est utilisée pour les transformations de format de données, la stratégie de transformation de la sortie exécute généralement la transformation des données dans le sens opposé (c'est-à-dire que les données sont converties du format du coffre-fort d'identité au format de l'application). Cette règle s'applique dans l'espace de noms de l'application. Elle peut servir à reformater des données, comme par exemple faire passer un numéro de téléphone du format 1(815)555-1212 au format 1-815-555-1212. La règle de transformation de l'entrée est également utilisée pour mener des actions en réponse aux résultats des commandes envoyées au module d'interface. Les noms des schémas sont toujours dans l'espace de noms de l'application dans le fichier XML traité par la stratégie de transformation de l'entrée. Il est également possible d'utiliser la règle de transformation de l'entrée pour convertir un format XML arbitraire natif de l'application connectée au format attendu par Identity Manager. De telles transformations doivent être écrites en XSLT car le script DirXML s'applique uniquement au vocabulaire XML spécifique à Identity Manager.
6.13.2 Règle de transformation de la sortie
La stratégie de transformation de la sortie s'applique à la fois au canal Abonné et au canal Éditeur. La stratégie de transformation de la sortie a pour objectif de réaliser une transformation finale sur tous les documents XML envoyés et renvoyés au module d'interface par le moteur Identity Manager. La règle de transformation de la sortie est appliquée aux documents XML envoyés aux commandes SubscriptionShim.execute et XmlQueryProcessor.query lorsqu'ils sont appelés par le moteur Identity Manager et aux documents XML renvoyés depuis XmlCommandProcessor.execute et XmlQueryProcessor.query lorsqu'ils sont appelés par le module d'interface. La règle de transformation de la sortie est appliquée après celle d'assignation de schéma.
La règle de transformation de la sortie est le contraire de la règle de transformation de l'entrée. Elle modifie adéquatement la commande sur le point d'être soumise au module d'interface. Cela implique généralement l'annulation de ce qui a été effectué dans la règle de transformation de l'entrée. Par exemple, si vous avez une règle de transformation de l'entrée qui convertit les numéros de téléphone du format 1(815)555-1212 au format 1-815-555-1212, vous devez avoir une règle de transformation de la sortie qui convertit le format 1-815-555-1212 au format 1(815)555-1212.
Il est également possible d'utiliser la stratégie de transformation de la sortie pour convertir le format utilisé par Identity Manager au format XML arbitraire natif à l'application connectée. De telles transformations doivent être écrites en XSLT car le script DirXML s'applique uniquement au vocabulaire XML spécifique à Identity Manager.
6.13.3 Associations
La valeur d'association constitue un moyen pour Identity Manager de savoir quel objet du système connecté correspond à un objet du coffre-fort d'identité. Dans presque tous les cas, il doit s'agir d'une concordance 1:1 pour qu'il soit possible de dire que « john doe », employé numéro 1234567 dans le système HR correspond exactement à l'objet Utilisateur « jdoe13 » dans le coffre-fort d'identité, à « doe john » dans Active Directory et à « jdoe13@exemple.com » dans le système de messagerie. La plupart des systèmes informatiques possèdent une certaine forme d'identifiant unique interne. eDirectory et Active Directory ont un identificateur global unique ou GUID. De nombreux systèmes HR présentent un numéro d'employé. Les systèmes de messagerie électronique possèdent en général une valeur d'adresse électronique unique pour chaque personne. Identity Manager utilise ces identifiants pour créer son association. Les associations sont stockées dans le coffre-fort d'identité. Sur le canal Abonné, le moteur Identity Manager utilise cette valeur pour permettre au module d'interface de modifier l'objet adéquat dans le système connecté. Sur le canal Éditeur, le module d'interface fournit la valeur d'association, ce qui permet au moteur Identity Manager de rechercher rapidement et facilement l'objet correct dans le coffre-fort d'identité.
6.13.4 Ajouts synthétiques
Si l'opération de modification ne contient pas d'association se résolvant sur un objet réel lorsqu'il arrive au niveau du processeur d'ajout, le moteur Identity Manager convertit l'événement de modification en un processus d'ajout synthétique. Il s'agit du processus d'ajout synthétique, qui peut se produire sur le canal Éditeur ou Abonné. Le moteur Identity Manager utilise l'événement de modification pour déterminer l'objet à utiliser. Il utilise ensuite le filtre pour renvoyer une requête afin d'obtenir tous les attributs disponibles pour cet objet qui sont définis sur Sync ou Notifier sur le canal actif. Il supprime ensuite l'événement de modification et crée un événement d'ajout pour le remplacer. Cet événement d'ajout est ensuite transmis via les règles de concordance, de création, de placement et de transformation de commande (sur le canal Abonné, il passe aussi par l'assignation de schéma et la transformation de la sortie). La règle de transformation de l'événement n'est pas déclenchée pour les ajouts synthétiques, cette règle se trouvant en amont du processeur d'ajout.
Figure 6-4 Processeur d'association du canal Abonné
6.13.5 Traitement des fusions
Une opération de fusion se produit lorsque le moteur Identity Manager convertit une opération d'ajout en une opération de modification. Cette conversion a généralement lieu lors d'une migration initiale, lorsque la migration envoie des objets via un canal et que la règle de concordance identifie un objet qu'elle peut associer à l'objet en cours de migration.
Lors d'une opération de fusion, le document actif est rejeté (comme l'ajout synthétique) et le filtre est utilisé pour interroger à la fois le système connecté et le coffre-fort d'identité pour toutes les valeurs. Le paramètre de chaque attribut du filtre est utilisé afin de décider des opérations à effectuer avec les données. Il est, entre autres, possible de remplacer les informations de la source par les informations de la cible, de remplacer la cible par la source, d'associer les deux et de mettre à jour les deux avec les résultats, ou de ne rien faire. Les diagrammes de flux ci-dessous décrivent le processeur de fusion du canal Éditeur et le processeur de fusion du canal Abonné.
Figure 6-5 Processeur de fusion du canal Éditeur
Figure 6-6 Processeur de fusion du canal Abonné
