Identity and Access Management
Dans le cadre d'un projet de migration de ITIM 5.1 vers ISIM 6, nous avons eu la malchance (il n'y a pas d'autre terme) de devoir installer ISIM (IBM Security Identity Manager) sur un serveur Windows 2012 R2.
La conclusion est sans appel : ce n'est pas fait pour. Autant l'installation sur un Linux Red Hat prend quelques heures (avec un jeu de scripts shell), autant sur Windows 2012 on peut y passer plusieurs semaines (sans mentir).
Dans les versions 2.1, 3.0 et 3.1, OpenIDM fournit un script shell qui permet de mettre en place la rotation des fichiers d'audit (OPENIDM_HOME/bin/create-openidm-logrotate.sh).
Par contre ce script a 2 inconvénients à mon sens :
Une fois n'est pas coutume, cet article ne sera pas (trop) orienté technique, mais fait plutôt suite à un retour d'expérience sur un projet qui se termine, et dans lequel la souplesse de OpenIDM et son côté "boîte à outils" ont permis de faire des choses qui auraient été compliquées à faire avec un autre outil (sachant que la principale solution avec laquelle je peux comparer est IBM ISIM).
La version 4 de OpenIDM est disponible depuis fin janvier 2016 (cf. les Release Notes).
Cette nouvelle version apporte son lot de changements, qui améliorent encore un peu le produit. On peut notamment citer des nouveautés du côté de l'interface d'administration :
J'ai eu récemment le cas d'un client qui voulait, lors de la suppression d'un objet user, mettre à jour l'annuaire LDAP sur lequel l'utilisateur avait un compte, plutôt que supprimer ce compte.
Pour cela, il faut tout d'abord modifier l'action liée à la situation SOURCE_MISSING, pour utiliser Unlink plutôt que Delete (en fait, si on garde l'opération Delete, on peut lancer un script, mais l'objet cible sera quand même supprimé par la suite).
Par défaut, le schéma de données de ITDS (IBM Tivoli Directory Server) est chargé au démarrage, à partir du fichier V3.modifiedschema, présent dans le répertoire /etc de l'instance d'annuaire.
Par exemple, pour une instance nommé idsldap, le fichier sera dans le répertoire /product/ldap/idsslapd-idsldap/etc.
Si on veut ajouter un attribut ou une classe d'objet à notre schéma, il est évidemment possible d'arrêter le serveur, modifier le fichier V3.modifiedschema, puis redémarrer ITDS.
Dans un environnement OpenIDM 3.1, nous utilisons le connecteur ActiveDirectory 1.4.0.0, le mspowershell-connector-1.4.1.0 et le connecteur ICF .Net 1.4.1.0 (openicf-zip-1.4.1.0-dotnet.msi).
L'idée est de lancer un script powershell à la création d'un utilisateur dans l'Active Directory, afin de positionner certains paramètres et créer le Home Directory.
OpenIDM permet de valider le format des attributs, via des policies.
Ces règles sont définies par défaut dans le fichier OPENIDM_HOME/bin/defaults/script/policy.js. On y trouve par exemple des règles de type : required, not-empty, unique, valid-date, valid-email-address-format, min-length et bien d'autres. Une vingtaine de règles sont ainsi disponibles, mais il est également possible d'ajouter des règles spécifiques si besoin.
Les différentes étapes pour ajouter une règle spécifique sont les suivantes :
L'architecture OpenIDM est très orientée "boîte à outils", à la différence de solutions telles que IBM Security Identity Manager.
Même si depuis la version 3.1 on dispose d'une interface d'administration, qui permet de réaliser une partie du paramétrage de la solution - notamment au niveau des mappings, une grande partie de la mise en oeuvre et de la personnalisation passe par des fichiers de configuration json et des scripts, javascript ou groovy.
Cette page donnera quelques problèmes et solutions rencontrées lors de la mise en place de OpenIDM.
J'espère qu'elle pourra servir à d'autres, en tout cas elle me servira de pense-bête :-)