Interaction avec IBM Tivoli Directory Server 5.2 (LDAP)

Un annuaire LDAP (Lightweight Directory Access Protocol) est une liste d'informations placées dans un ordre particulier et comportant des informations détaillées sur chaque objet. LDAP est une base de données spécialisée possédant des caractéristiques qui la différencient des bases de données relationnelles génériques. L'une des caractéristiques propres aux annuaires est que les opérations d'accès aux informations (lecture ou recherche) sont beaucoup plus fréquentes que les opérations de mise à jour d'informations (écriture). Par exemple, des centaines de personnes peuvent rechercher le numéro de téléphone d'une personne mais ce numéro change très rarement.

IBM Telephone Directory version 5.2 permet de rechercher, d'afficher et de gérer les entrées d'un annuaire ou de configurer un nouvel annuaire. L'application utilise un serveur d'annuaires LDAP pour stocker et extraire les données. Par défaut, le serveur LDAP est automatiquement configuré sur le serveur sauf si un serveur LDAP est déjà disponible sur le réseau. Le serveur LDAP ne doit pas forcément résider sur le même système que le serveur d'applications. En outre, vous pouvez utiliser un serveur LDAP Domino avec IBM Telephone Directory. Pour plus d'informations, voir le document technique (Redpaper) WebSphere Application Server Express. Lien hors du composant Information Center

Le serveur LDAP est accessible via TCP/IP.

Entrées LDAP

Le seul paramètre par défaut défini lors de l'installation d'IBM Telephone Directory version 5.2 consiste à autoriser les utilisateurs à lancer des recherches anonymement dans l'annuaire.

Lorsque vous utilisez l'application IBM Telephone Directory version 5.2 pour ajouter une entrée à l'annuaire, le système crée une entrée dans le nom distinctif parent de l'utilisateur et fait appel à la valeur de l'ID utilisateur. Par exemple, si vous enregistrez le nom Jean Gautier dans le nom distinctif cn=users,dc=myhost,dc=mycompany,dc=com, cette entrée LDAP correspond à cn=Jean Gautier,cn=users,dc=myhost,dc=mycompany,dc=com. La mise à jour du nom distinctif parent n'est pas visible pour l'utilisateur ni l'administrateur IBM Telephone Directory version 5.2. Les objets de cet annuaire sont référencés par un attribut de nom distinctif (DN). Lors de l'authentification, le système invite Jean Gautier à entrer son ID utilisateur. Vous devez entrer l'ID utilisateur indiqué lors de l'enregistrement. Dans cet exemple, l'ID utilisateur est Jean Gautier.

Il est possible de rechercher, d'afficher et de gérer les entrées de l'annuaire, si elles sont définies en fonction de la classe d'objets inetOrgPerson standard. Cet annuaire peut contenir des entrées pour d'autres classes d'objets, notamment les classes d'objets utilisées par l'application pour lancer des recherches dans l'annuaire ; toutefois, la classe d'objets par défaut est inetOrgPerson.

Une classe d'objets auxiliaire appelée ibm-itdPerson est ajoutée aux entrées d'annuaire modifiées par l'application. La classe d'objets ibm-itdPerson permet à l'application IBM Telephone Directory version 5.2 d'utiliser des attributs supplémentaires qui ne sont pas disponibles avec les classes d'objet standard. Ces attributs incluent des numéros de téléphone et des adresses supplémentaires, des valeurs DN pour les assistants et les remplaçants et des informations sur le site de l'entreprise, telles que la fonction, la zone marketing et la zone commerciale. Tous les attributs de la classe d'objet auxiliaire ibm-itdPerson sont facultatifs. La classe est ajoutée pour permettre de stocker des informations supplémentaires sur une personne, qui ne sont pas disponibles dans la classe d'objets inetOrgPerson.

Lorsque l'application reçoit une demande, elle doit se connecter au serveur LDAP pour la traiter. Les demandes sont exécutées sous l'autorité de l'utilisateur indiqué. L'application utilise les justificatifs transmis dans les demandes HTTP pour se connecter au serveur LDAP, si nécessaire. L'application requiert des justificatifs pour certaines demandes, telles que les demandes de création, de mise à jour ou de suppression d'entrées d'annuaire. Les justificatifs requis pour ajouter des entrées sont fournis par l' administrateur lorsque la fonction d'enregistrement en mode ouvert est activée.

Si des justificatifs ne sont pas nécessaires pour effectuer des recherches, l'application se connecte au serveur LDAP à l'aide d'une liaison anonyme pour lancer une recherche dans l'annuaire. Dans le cas d'une recherche en mode anonyme, la propriété de configuration Directory Access doit correspondre à Anonymous (no login). Si des justificatifs sont requis pour traiter des demandes de recherche, l'application se connecte au serveur LDAP à l'aide des justificatifs de l'utilisateur transmis dans les demandes HTTP. La demande échoue si des justificatifs ne sont pas fournis. Dans le cas d'une recherche avec authentification, la propriété Directory Access doit correspondre à Login Required. Pour plus d'informations, voir Modification de l'accès à l'annuaire.

Le serveur LDAP contrôle les opérations que les utilisateurs sont autorisés à effectuer et vérifie si leur demande aboutit ou échoue. Ce mécanisme s'applique également aux demandes effectuées en mode anonyme. Tous les paramètres gérant les droits d'accès à l'annuaire sont définis et contrôlés par le serveur LDAP. L'application convertit les demandes HTTP en demandes LDAP, vérifie que les justificatifs sont traités et transmis au serveur LDAP en toute sécurité et affiche les résultats LDAP (réussite ou échec) au format HTML, sous la forme d'un carnet d'adresses simple.

Les utilisateurs fournissent les justificatifs que l'application utilise pour se connecter au serveur LDAP. Les justificatifs des utilisateurs ne permettent pas de se connecter au serveur LDAP lorsque la fonction d'enregistrement en mode ouvert est activée. Pour l'enregistrement en mode ouvert, les justificatifs sont lus à partir du fichier de configuration de l'application. Le serveur HTTP doit authentifier l'utilisateur lorsque cela s'avère nécessaire. L'application utilise les justificatifs fournis dans chaque demande (si nécessaire) pour se connecter au serveur LDAP. L'application ne place pas les justificatifs en mémoire cache et ne réutilise pas les connexions LDAP pour traiter plusieurs demandes HTTP. Les connexions LDAP sont arrêtées après chaque demande pour empêcher l'application de se connecter en utilisant les justificatifs d'un utilisateur pour traiter la demande d'un autre utilisateur. Si le serveur HTTP ne fournit pas les justificatifs nécessaires pour se connecter au serveur LDAP, l'application échoue.