Introduction
La gestion des identités en entreprise est une problématique de plus en plus importante. En effet, des thématiques telles que la mise en place d'un référentiel d'identité unique, le SSO (authentification unique), la gestion du cycle de vie d'un utilisateur (provisioning et deprovisioning, gestion du mot de passe, …) et bien d'autres deviennent essentielles dans des environnements toujours plus complexes et offrant plus de services. Il devient donc primordial d'intégrer des solutions permettant de gérer les identités au sein d'une entreprise. Cela permet notamment :
-
d'automatiser des processus de gestions de comptes (exemple la saisie/modification/suppression d'un compte dans une base RH déclenche les actions nécessaires sur les infrastructures du système d'information)
-
d'éviter les erreurs humaines de manipulations
-
de réduire les tâches d'exploitation
-
de n'avoir qu'un seul point d'entrée pour la saisie d'informations (référentiel RH par exemple, …)
Dans cette série d'articles, nous allons nous intéresser au composant Synchronisation Service. Si certains composants fonctionnent ensemble, ce n'est pas le cas de celui-ci qui peut être installé seul. L'objectif est de découvrir les possibilités offertes par cet outil. Pour cela, nous allons utiliser le contexte d'une société "MyCompany" souhaitant synchroniser les changements de son référentiel d'identité (une base de données SQL Server) vers l'annuaire Active Directory (synchronisation d'attributs). Aussi, nous verrons comme gérer le cycle de vie des objets tels que les utilisateurs ou les groupes via un mécanisme de Provisioning/Deprovisioning.
Ces articles vont s'articuler de la façon suivante :
Durant la configuration des Managements Agents, j'ai évoqué plusieurs configurations pouvant être personnalisées via du développement. Malgré que cela puisse paraître compliqué, il n'est pas nécessaire de posséder de très grandes compétences en développement pour réaliser ce type d'implémentation. Le langage utilisé est le VB.Net ou le C#. Dans cet article j'utiliserai le C#. J'expliquerai comment créer une règle d'extension à partir de FIM, les notions liées à FIM pour le développement de celles-ci, ainsi qu'un exemple concret avec une règle simple réalisant une transformation d'un attribut lors d'un d'import. Pour réaliser ce guide, il est nécessaire de posséder Visual Studio (en version 2008 ou supérieure).
NB : En Août 2015, Microsoft a sorti une nouvelle version de la suite FIM, renommé pour l'occasion MIM (Microsoft Identity Manager) suite à l'abandon de la gamme de produits Forefront. Cette nouvelle mouture apporte quelques fonctionnalités supplémentaires. Cependant le contenu de ces articles restent valables.
Ajout d'une règle d'extension
Avant de créer le projet Visual Studio est de développer nos règles personnalisés, il faut les ajouter au sein du Management Agent. Prenons l'exemple d'une règle standardisant le formatage du prénom des objets de type person. Celle-ci permettra d'avoir tous les prénoms avec la première lettre de chaque mot en majuscule et le reste en minuscule. Pour ce faire, il est nécessaire d'éditer le flux d'attribut du Management Agent. Dans cet article, nous allons effectuer cette modification lors de l'import des données dans la métaverse (dans le Management Agent SQL). Toutefois, cela aurait aussi été possible pendant l'export des données dans l'annuaire Active Directory et donc dans le Management associé (à la différence que la transformation ne sera pas visible dans la métaverse).
Le changement de flux d'attribut consiste à définir le type à Advanced au lieu de Direct.
Un panel s'ouvre. Il faut alors choisir le type Rule Extension. Le nom associé peut être customisé. Il sera utilisé lors du développement pour identifier les actions qui seront associées.
Enfin, il convient de définir le nom de la DLL dans l'onglet Configure Extensions. Ces dernières sont contenues dans l'arborescence 2010\Synchronization Service\Extensions du dossier d'installation de FIM Synchronisation Service (par défaut C:\Program Files\Microsoft Forefront Identity Manager\).
Attention, lorsque cette configuration est appliquée, le Management Agent n'est plus fonctionnelle tant que la DLL n'a pas été créée. De plus, le flux d'import échouera si la méthode permettant de traiter cette règle avancée n'a pas été implémentée dans la DLL.
Création du projet Visual Studio
Les règles d'extensions reposent sur une DLL que l'on peut générer à partir de Visual Studio. Aussi, FIM Synchronisation Service inclus des options permettant de simplifier le développement de celles-ci. Ainsi, il va être possible de générer un projet et l'intégralité du squelette C# ou VB.Net. Ce dernier contient toutes les règles de personnalisation qu'il convient ou nous de compléter en fonction de ses besoins. Il ne restera plus qu'à compléter le projet. Une méthode C# correspond à chaque personnalisation possible (c’est-à-dire à chaque endroit dans la configuration du Management Agent où l'on peut indiquer une règle d'extension). Nous reviendrons sur les possibilités offertes par chaque méthode dans le chapitre suivant. Si les règles à intégrer sont simples, il ne faudra alors que quelques lignes pour mettre en place ce type de configuration (c'est ce que nous verrons dans l'exemple décrit en fin d'article).
Par convention, une dll d'extension est attribuée à un Management Agent à la fois. Celle-ci contiendra donc toutes les règles de personnalisation d'un Management Agent. Pour créer une nouvelle règle d'extension. Il est nécessaire de se rendre dans l'onglet Management Agent, de sélectionner le Management Agent pour lequel on souhaite développer une règle d'extension puis de cliquer sur le menu Actions et enfin de cliquer sur Rules Extension dans Create Extension Projects.
Un assistant permet de définir le langage, la version de Visual Studio, le nom du projet et l'emplacement où il sera stocké. A noter que si vous utiliser une version supérieure à Visual Studio 2012, vous pouvez indiquer cette dernière comme version cible. Aussi, en cochant la case Launch in VS.Net IDE, vous avez la possibilité d'ouvrir directement le projet dans Visual Studio. Cette option ne sera fonctionnelle que si Visual Studio est installé sur le même serveur que FIM Synchronisation Service. Cette implémentation est en général envisageable lorsque l'on travaille sur un serveur de développement. Il suffira ensuite d'exporter le Management Agent et la DLL sur le serveur de production.
Lorsque le projet est ouvert, on constate que l'arborescence reste simple. Le fichier qui nous intéresse est celui avec l'extension .cs portant le nom de la règle d'extension. Le développement à réaliser ne concernera que la modification de ce fichier.
Lorsque vous générer la solution via le menu Build, la DLL est automatiquement placée dans le répertoire adéquat de FIM Synchronisation Service.
Notions
Les méthodes
En dehors des méthodes initialize et terminate qui ne s'exécute qu'une seule fois par exécution d'un Management Agent, les autres méthodes sont appelées pour chaque objet qui est traité lorsqu'il satisfait une configuration appelant une règle d'extension (la règle de flux d'import par exemple). Chaque méthode ne peut donc modifier qu'un objet d'un connector space ou de la métaverse à la fois.
Initialize
Cette méthode est exécutée la première fois qu'une règle d'extension est appelée lors de l'exécution d'un Management Agent. Elle permet de gérer un code d'initialisation du Management Agent comme le chargement de paramètres via un fichier XML (exemple : des paramètres de logging, une ouverture de connexion à une base de données).
Terminate
Contrairement à la première méthode, celle-ci est appelée lorsqu'aucune règle d'extension n'a été exécutée depuis 5 minutes (FIM considère alors que la synchronization est terminée). Celle-ci est utilisée pour libérer des ressources qui auraient pu être instanciées pendant la méthode initialize (exemple : clore la connexion à une base de données).
ShouldProjectToMV
Il s'agit d'une méthode influant le comportement des règles de projection. En temps normal, si aucune règle de jointure ne permet de créer un connecteur alors un objet d'un connector space est créé si une règle de projection a été défini. Lorsque cette dernière est configurée pour utiliser une règle d'extension alors on peut utiliser cette méthode pour traiter des cas particulier. En effet, le retour de cette méthode définit si l'objet doit être projeter dans la métaverse ou non.
Deprovision
La méthode Deprovision est en charge de définir l'action de deprovisioning lorsqu'un objet d'un connector space est déconnecté suite à la suppression de son équivalent dans la métaverse. Au lieu de définir une seule action possible comme nous l'avions vu dans les articles sur la configuration des Management Agent, on peut choisir de calculer cette action en fonction de paramètres spécifiques. Les actions possibles restent les mêmes :
-
Déconnexion (l'objet peut être reconnecté s'il satisfait une règle de jointure ou une règle de projection)
-
Déconnexion explicite (l'objet ne peut être reconnecté automatiquement, il faut alors utiliser l'onglet Joiner)
-
Suppression (dans le connector space puis sur le système connecté lors du prochain export)
FilterForDisconnection
Cette méthode permet de définir un filtre personnalisé pour exclure des objets du connector space d'être synchronisé. Cela correspond à la règle d'extension que l'on peut configurer dans l'onglet Configure Connector Filter.
MapAttributesForJoin
MapAttributesForJoin offre la possibilité d'ajouter des valeurs calculés pour effectuer une jointure. Cette dernière retourne une collection d'attributs présent sur l'objet du connector space ou ajoutées par cette fonction.
ResolveJoinSearch
Grâce à cette méthode, il est possible d'affiner la résolution d'une jointure lorsque des règles directes ne peuvent pas faire correspondre un objet d'un connector space avec un objet de la metaverse. En effet, il est ainsi possible d'éviter le cas où plusieurs objets de la metaverse correspondent.
MapAttributesForImport
et
MapAttributesForExport
Il s'agit des méthodes permettant de gérer les flux d'attributs entre la metaverse et le connector space (et à fortiori le système connecté). La première est en charge des modifications d'attributs lors des opérations d'import (connector space vers metaverse) tandis que la seconde est utile pour les opérations d'export. Grâce à elles, il est possible de transformer des attributs. On peut aussi utiliser plusieurs attributs en entrée pour calculer la valeur d'un attribut en sortie. La méthode MapAttributesForImport ne permet de modifier qu'un objet de la métaverse (l'objet correpondant dans le connector space n'est accessible qu'en lecture) et vice versa pour la méthode MapAttributesForExport.
NB : Par défaut, toutes les méthodes possèdent la ligne de code ci-dessous :
Celle-ci signifie qu'aucun traitement n'a été implémenté. Néanmoins, il n'est pas nécessaire de changer ce comportement pour les méthodes qui ne seront jamais appelées par le Management Agent.
Les variables
csentry
Cette variable correspond à l'objet au sein du connector space en cours d'accès.
mventry
Cette variable correspond à l'objet au sein de la métaverse en cours d'accès.
flowRuleName
Il s'agit du nom de la règle qui a été défini dans le Mangement Agent. En effet, la dll contient toutes les règles d'extension. Par exemple, si nous définissons plusieurs règles avancées d'import lors du flux d'attribut, le code associé pour celles-ci sera inclus au sein de la méthode MapAttributesForImport. Cette variable permet ainsi de savoir qu'elle règle a été appelée pour exécutée le bon traitement. La convention est d'utiliser une structure algorithmique de type switch sur la valeur de cette variable pour différencier les règles d'extensions (nous verrons cette structure dans le paragraphe suivant).
Exemple de règle d'import
Le but de cet exemple simple et de montrer le code nécessaire à la standardisation du format de l'attribut firstname comme nous l'avons vu au début de cet article lors de la configuration de la règle d'extension.
Astuce : Si vous ajouter toutes vos règles d'extension dans la configuration du Management Agent avant de créer le projet Visual Studio alors la structure algorithmique contenant les différents nom de règles est pré générée. Cela facilite encore plus le développement.
Vous trouverez ci-dessous la fonction MapAttributesForImport complète. On remarque qu'un test est effectué afin de savoir si l'objet du connector space possède une valeur pour l'attribut firstname. Si tel est le cas, la valeur est récupérée(grâce à la variable csentry) via la propriété value. Elle est ensuite formatée (première lettre de chaque mot en majuscule) puis affectée à l'objet correspondant dans la métaverse (via la variable mventry) Le cas par défaut remonte une erreur d'implémentation si aucune règle porte le bon nom de la structure de type switch :
Il ne reste plus qu'à compiler la solution via le menu Build afin que la dll soit générée dans le répertoire adéquat. Cet exemple se veut simple mais il est possible d'imaginer des cas de personnalisations beaucoup plus complexes ou faisant intervenir d'autres types de configuration (filtrage, jointure, …) via les autres méthodes disponibles.
NB : Même si cette possibilité n'a pas été utilisée dans cet exemple, une méthode permet de rechercher des objets dans la métaverse. Ces derniers ne sont toutefois accessibles qu'en lecture. Néanmoins cela peut être utile pour consolider des informations dans l'objet en cours de traitement (le manager d'un employé par exemple). L'une des façons les plus simples de l'utiliser correspond à l'exemple ci-après :
Le premier paramètre est le nom de l'attribut sur lequel la recherche est effectuée (quelque soit le type d'objet) tandis que le second correspond à la valeur attendue. Il est fortement recommandé d'effectuer cette recherche sur des attributs indexés afin d'optimiser le temps de traitement.