Identity and Access Management
Dans IBM Tivoli Identity Manager (ITIM), si une réconciliation est interrompue en cours (plantage du service ou de WebSphere), le service reste marqué comme étant en cours, et "locké". Il n'est plus possible alors de faire des mises à jour sur ce service.
OpenIDM, la solution de gestion des identités de Forgerock, va bientôt sortir en version 3.1, avec un grand changement par rapport aux versions précédentes : une interface d'administration / configuration.
Jusqu'ici, la configuration se faisait uniquement via des fichiers Json, ce qui avait l'avantage de pouvoir être facilement versionné, mais plaçait le produit loin de ses compétiteurs quant à l'aspect "interface d'admin".
Dorénavant, il est possible d'avoir une visu des ressources, en se connectant à http://localhost:8080/admin
La mise en place de SSL pour OpenLDAP permet de sécuriser les échanges, que ce soit en utilisant LDAPS ou START/TLS (dans ce dernier cas, la connexion démarre sur le port LDAP et passe ensuite en mode sécurisé).
En préalable, on aura généré une clé privée, récupéré un certificat, ainsi que celui de l'autorité de certification. (voir un article précédent sur le mémento OpenSSL ).
Les étapes pour la sécurisation sont :
Les droits d'accès sur les objets du DIT OpenLDAP sont contrôlés par des ACL (Access Control List), qui sont stockés au niveau du rootSuffix.
Par exemple, on peut récupérer les règles via une requête telle que :
Par défaut, les attributs d'un annuaire OpenLDAP ne sont pas indexés. Comme dans une base de données, ceci peut impacter les performances de l'annuaire, en introduisant des full scan qui balaient toutes les entrées. Il est possible, comme sur une base de données, de créer des index sur certains attributs, pour améliorer la vitesse de recherche.
Toutefois, les index ont également un inconvénient : lors des mises à jour, l'index doit être recalculé, et ceci peut être pénalisant, notamment lors de modifications en masse.
Dans un environnement ITIM, qui utilise une base Oracle, on a parfois des messages d'erreurs dans le fichier WebSphere SystemOut.log :
Par défaut, ITIM utilise la time-zone de WebSphere, qui n'étant pas définie, peut être différente de l'heure du serveur.
Nous avons eu le souci sur une installation en Russie : le paramétrage des réconciliations utilisait l'heure française :
Dans la série des overlays pour OpenLDAP, après le Password Policy, regardons l'accesslog.
L'overlay Accesslog peut être utile pour récupérer dans une branche séparée de l'annuaire un ensemble d'opérations appliquée sur une database.
Le paramétrage distingue 4 sortes d'opérations :
Par défaut, OpenLDAP implémente strictement les RFC du protocole LDAP, et ne dispose que de (relativement) peu de fonctionnalités par rapport à ses concurrents.
Il existe cependant un mécanisme d'overlays, qui permet de modifier et enrichir le comportement de cet annuaire.
On y trouve notamment (cf. http://www.openldap.org/doc/admin24/overlays.html) :
Dans certaines règles de provisionnement (Provisioning Policies), il est parfois nécessaire de construire le DN du manager, par exemple pour alimenter un champ manager dans un annuaire LDAP ou Active Directory, qui sont des DN.
Inutile donc, dans ce cas, de mettre uniquement le matricule ou le nom du manager, il faut soit construire, soit récupérer la valeur du DN du manager dans le service distant.
Voyons comment ceci peut être réalisé dans une PP ITIM, selon les cas.