Et… Ca marche ! Avec Oracle 10g, les « username/password » des Enterprise Users peuvent être validé dans OID même si le mot de passe n’est pas alimenté en clair mais en SHA-1 (ce qui est le cas lorsqu’on on récupère les informations de iPlanet dans le paramètrage que j’effectue). Ce que j’ai fait :

• J’ai paramétré EUS de sorte que j’arrive à me connecter sous greg/manager1
• J’ai modifié le mot de passe avec « LDAP Browser /Editor » mais au lieu de saisir le mot de passe en clair, j’ai saisi sa forme hashée par l’algorithme SHA-1 (i.e. : {SHA}eeJHX4GmMXJ2v3y7OViyDSibeN8= au lieu de greg, cf image ci-dessus)
• Je constate que l’attribut orclpassword n’est pas renseigné (cf image ci-dessus). L’attribut authpassword;orclcommonpwd contient uniquement la valeur saisie (i.e. {SHA}eeJHX4GmMXJ2v3y7OViyDSibeN8 ).
• Quand je me connecte avec SQL*Plus 10.2 avec le mot de passe greg (Ca marche ! YES !) alors que si je me connecte avec l’ancien mot de passe (manager1), ça ne marche plus.

Et alors ?
L’étape d’après c’est de valider que ça marche avec la delegated authentication plugin si on ne veut pas faire la synchronisation du mot de passe dans OID mais laisser une seule version du mot de passe dans iPlanet. Quoiqu’il en soit, les restrictions liées à Oracle9i sont désormais levées dans la version 10g…

Avec quels clients ça marche ? J’ai testé avec SQL*Plus 10.1.0.4.2 et 10.2.0.2 avec succès. Par contre, il faut noter que :

• Les drivers JDBC Thin 10.2.0.2 sans paramétrages spécifiques ne fonctionnent pas si le mot de passe est stocké directement en SHA-1 dans OID (et donc l’attribut orclpassword non renseigné). L’erreur générée est « ORA-28274: No ORACLE password attribute corresponding to user nickname exists. ». D’après ma compréhension, c’est une théorie pour l’instant, le client « hashe » lui-même le mot de passe et le transmet à la base de données. Il est probable qu’il faille (a) soit faire un paramétrage spécifique du client, (b) soit attendre une version ultérieure si l’algorithme n’est pas encore implémenté. J’ai ouvert un appel pour vérifier ce point.
  
• Comme on peut s’y attendre, les drivers OCI de la version 9i ne fonctionnent pas non plus et pour les mêmes raisons. Le même message d’erreur s’affiche lorsque vous essayez de vous connecter et que le mot de passe n’a pas été saisi en clair mais à partir de sa forme hashée en SHA-1: « ORA-28274: No ORACLE password attribute corresponding to user nickname exists ».

Conclusion…
A quelques restrictions prêt (Utiliser l’Instant Client avec JDBC OCI plutôt que JDBC Thin) et avec Oracle 10.2, il est possible de gérer des utilisateurs de base de données de manière centralisée dans un annuaire tiers comme iPlanet et ceci, même si l’annuaire existe déjà et que les mots de passe y sont stockés en SHA-1. On pourra ensuite remplacer iPlanet par OID, non ?

GarK !

Nota Bene:

• En SSHA (Salted SHA) je n’ai pas trouvé le moyen de le faire fonctionner la synchronisation. Je pense qu’il n’est pas possible de partager les clé de « Salted » entre plusieurs annuaires (En fait, ça reste une question plus qu’une affirmation).
• La complexité du mot de passe n’est pas vérifiée par OID lorsque le mot de passe est écrit directement en SHA-1 dans le champ userpassword. Ceci est logique puisque l’algorithme n’est pas réversible et on voit mal comment OID pourrait faire ce test !
• Une dernière bonne nouvelle : on n’est pas obligé d’utiliser un certificat pour la connexion entre la base 10.2 et OID 10.1.2. Un simple paramétrage / fonctionne et ça m’a pris moins de 1 heure pour mettre en place EUS avec ma base de données !