IAM

Identity and Access Management

OpenIDM - comment remplacer la suppression par une mise à jour

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).

ITDS : modifier le schéma en live

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.

Mise en place de politiques de validation dans OpenIDM

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 :

Paramétrage et personnalisation OpenIDM

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.

Mise en place d'un cluster OpenIDM

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

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.

OpenDJ : personnalisation du schéma

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: