Dans un environnement client OpenIDM 3.1 en production depuis plusieurs mois, l'accès à l'écran d'administration des mappings met de plus en plus longtemps à s'afficher.
It may help : if the access time to mapping administration form in OpenIDM becomes very slow, then check the numbers of lines in auditrecon table, and delete old records.
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 :
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.
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 :-)
OpenIDM est prévu pour s'installer et fonctionner en mode cluster, de manière assez facile.
Chaque instance partage le même repository, ce qui leur permet de disposer des mêmes données, la configuration étant alors partagée. Seul le repository est utilisé pour le cluster, sans autre mécanisme (pas de test de lien réseau par exemple).
Cet article explique comment démarrer deux instances OpenIDM qui vont partager le même repository et utiliser une ressource LDAP commune (OpenDJ dans notre exemple).
OpenIDM est la solution de gestion des identités orientée "provisionnement", proposée par Forgerock.
A la différence des produits OpenDJ (issu de OpenDS) et OpenAM (issu de OpenSSO), c'est une solution entièrement nouvelle. Ecrite en java, elle évolue et se bonifie rapidement au fil des ans.
L'un de ses principales particularités est de proposer des interfaces REST pour la quasi-totalité des opérations.
Il est d'usage courant de personnaliser le schéma de données, en ajoutant des attributs et des classes d'objets spécifiques au client.
OpenDJ permet bien évidemment de définir son propre schéma de données. La déclaration des attributs et classes d'objets est faite dans différents fichiers LDIF, chargés au démarrage de l'instance, et qui se trouvent dans $DJHOME/config/schema.
Par défaut, après l'installation, on y trouve une quinzaine de fichiers: