Proxy Ldap

Projet de Fin dtudes
Rapport de soutenance
Olivier Schmitt
Yannik Soubigou
Rapport de projet
de fin dtudes ENSIMAG
Conception et Ralisation
dun proxy dannuaire LDAP
Etudiants : Olivier Schmitt et Yannik Soubigou

Tuteur Ensimag : Brigitte Plateau
Encadrement Bull : Marc Fleurisson
Dure : du 1er janvier au 30 juin 2000
Lieu : Bull SA 1, rue de Provence 38432 Echirolles
Date: 27/06/00
Page:1/46

Date: 27/06/00
Page:2/46
Olivier Schmitt
Yannik Soubigou
I. Table des matires

I.
Table des matires _____________________________________________________________2
II. Remerciements________________________________________________________________4
III.
Introduction ________________________________________________________________5
A. Gnralits __________________________________________________________________5
B. Contexte ____________________________________________________________________5
C. Sujet_______________________________________________________________________5
IV.
Contexte de ralisation du projet ________________________________________________7
A. La socit BULL _____________________________________________________________7

B. Bull France _________________________________________________________________7
C. Le service Consulting et Systmes dIntgration _____________________________________8
V. Etude bibliographique __________________________________________________________9

A. LDAP et les annuaires _________________________________________________________9
B. Le protocole LDAP __________________________________________________________10
C. Lencodage BER de la grammaire ASN1 de LDAP __________________________________11
D. Les referrals de LDAPv3 ______________________________________________________11
E. Proxy LDAP et cahier des charges _______________________________________________12
1. Proxy LDAP ______________________________________________________________12

2. Cahier des charges _________________________________________________________12
F. Les Outils tudis ____________________________________________________________13
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
VI.
LAPI JNDI de Sun (Java Naming and Directory Interface)_________________________13

Netscape Directory SDK 4.0 for Java __________________________________________14
Netscape Directory SDK 4.0 for C_____________________________________________14
Loutil Snacc4Java dIBM ___________________________________________________14
Le couple Cup/Jlex_________________________________________________________15
Les outils dOSS Nokalva ___________________________________________________15
Les outils fournis par les chercheurs de luniversit du Michigan_____________________15
Les outils fournis par le groupe OpenLDAP _____________________________________16
Les proxy LDAP disponibles sur le march ______________________________________16
Les clients LDAP disponibles_______________________________________________17
Dveloppement _____________________________________________________________19
A. Phase prliminaire ___________________________________________________________19
1. Etude de larchitecture globale du logiciel_______________________________________19

2. Etude des librairies fournies par OpenLDAP _____________________________________21
B. Dveloppement dune interface LDAP ____________________________________________22
1. Structures de donnes _______________________________________________________22

Date: 27/06/00
Page:3/46
Olivier Schmitt
Yannik Soubigou
2. Choix darchitecture ________________________________________________________22

3. Choix de conception________________________________________________________22
C. Architecture globale du proxy __________________________________________________24
D. Algorithme de traitement des messages ___________________________________________26
E. Gestion de la rsolution des referrals _____________________________________________27
VII. Tests et validation ___________________________________________________________31

A. Tests et validation ___________________________________________________________31
1.
2.
3.
4.
5.
6.
Les tests de conformit______________________________________________________31

Les tests de stress __________________________________________________________31
Les tests dendurance _______________________________________________________32
Les tests de robustesse ______________________________________________________32
Les tests de choix de liaison (gestion des referrals)________________________________32
Les tests de performance ____________________________________________________33
VIII. Amliorations et Bogues _____________________________________________________36

A. Amliorations possibles _______________________________________________________36
B. Bogues et restrictions _________________________________________________________37
IX.
Planning __________________________________________________________________38
X. Conclusion __________________________________________________________________39
XI.
Bibliographie ______________________________________________________________40
XII. Annexes___________________________________________________________________41
A. Grammaire ASN1 pour LDAPv3 ________________________________________________41

Date: 27/06/00
Page:4/46
Olivier Schmitt
Yannik Soubigou
II. Remerciements
Nous voudrions remercier toutes les personnes qui par leur aide ou simplement par leur
gentillesse ont contribues dune faon ou dune autre la bonne ralisation du projet dont nous
avons eu la charge. Nous tenons donc remercier tous les membres de lquipe e-Solutions du site
dEchirolles pour leur disponibilit et leur sympathie.
Nous tenons tout particulirement remercier Antoine Geronimi, Thierry Dessenne, Jrme
Camilleri et Vladimir Plotto pour leur disponibilit, laide quils nous ont apporte et leur exprience.
Nous remercions galement Emmanuel Chabani, Pascal Deveze, Carole Hbrard et Serge Reboul.
Enfin, nous tenons tmoigner de toute notre sympathie pour les proches de notre matre de
stage Marc Fleurisson et de la douleur que son dcs a provoque en nous. Nous avions nou avec lui
des relations amicales qui dpassaient le cadre strictement professionnel. Il restera dans notre
mmoire.

Date: 27/06/00
Page:5/46
Olivier Schmitt
Yannik Soubigou
III. Introduction
A. Gnralits
Le prsent document est le rapport du projet de fin dtudes de Yannik SOUBIGOU et Olivier
SCHMITT, lves ingnieurs lENSIMAG. Il a comme but de situer le contexte du projet, de
dcrire son sujet, les mthodes et outils utiliss ainsi que les rsultats obtenus.
B. Contexte
Ce projet sest droul BULL Echirolles dans le service Consulting & Systmes dIntgration. Il a
t commenc mi-temps, de dbut janvier au 31 mars. Cette premire priode a t principalement
passe en tudes bibliographiques. Elle a t suivie de quatre mois plein temps.
Lencadrement tait initialement assur par Marc Fleurisson. Suite son dcs, Antoine Gronimi et
Thierry Dessenne se sont partags le rle de chef de projet.
C. Sujet
Les annuaires (norme ISO X500) permettent de grer de faon centralise les donnes de lentreprise
concernant les personnes, leurs habilitations, la configuration des logiciels, des donnes lies
larchitecture du rseau, les machines... Le protocole daccs et de requtes ces annuaires a t
nomm DAP (Directory Access Protocol). Ce protocole a t abandonn et remplac par le protocole
LDAP (Lightweight Directory Access Protocole) pour les accs par des clients lgers, qui est
beaucoup plus simple implmenter et utiliser. DAP est toujours utilis et support par des
annuaires DAP comme celui dISOCOR et LDAP constitue le protocole daccs par Internet. La
version 2 de ce protocole (RFC 1777) est trs largement supporte et la version 3 (RFC 2251) tend
aujourdhui devenir le standard daccs aux annuaires.
Le sujet initial du stage tait : Dveloppement dun Proxy LDAP. Il sagissait de dvelopper une
application qui, place entre un client et un serveur LDAP, pourra filtrer et modifier les informations
en transit.
REALISATION D'UN PROXY LDAP

CONTEXTE :
Les architectures Intranet s'appuient aujourd'hui notamment sur les serveurs d'annuaire LDAP, les
applications d'administration et de consultation d'annuaire ainsi que sur de nouveaux composants : les
proxys LDAP. Ceux-ci sont amens jouer un rle cl, en particulier le contrle d'accs aux
informations contenues dans l'annuaire.

Date: 27/06/00
Page:6/46
Olivier Schmitt
Yannik Soubigou
OBJECTIFS :
Fonctionnalits demandes : Le proxy LDAP proposera les fonctions de :
Gestion du contrle d'accs aux informations contenues dans les annuaires.
Distribution et agrgation des requtes LDAP sur les serveurs d'annuaire.
Cache des requtes.
Technologies mises en uvre : cette application sera ralise en Java (Application, Servlet, Applet),
mettra en uvre les protocoles et schmas d'Annuaire LDAP (interface JNDI), et sera scurise par
SSL.
PROFIL/COMPETENCES :
Comptences requises : Java, HTML, Unix.
Comptences souhaites : LDAP, NT.
Dure minimum : Janvier juin 2000 (pour 2 personnes).
Tuteur du stage : Marc FLEURISSON tel. 04 76 29 79 69
Logistique stage : Anne De DARASSUS tel. 04 76 29 75 80

Date: 27/06/00
Page:7/46
Olivier Schmitt
Yannik Soubigou
IV. Contexte de ralisation du projet

A. La socit BULL
Le groupe BULL est
lune des plus importantes
socits d'informatique en
Europe. Evoluant depuis le
dpt de brevet en Norvge
sur des machines cartes
perfores par Fredrik Rosen.
Bull
est
un
groupe
informatique international
bas en Europe qui emploie
18 358 personnes dans plus
de 100 pays. En 1999, il a
ralis un chiffre d'affaires
de 3,8 milliards deuros
dont plus de 65% hors de
France, son pays dorigine.
Bull fournit des solutions scurises pour le commerce lectronique et Internet portant
principalement sur trois domaines :
les solutions dintgration,
les solutions dinfrastructure garantissant haute disponibilit et scurit,
les solutions dinfo grance et de services de support.
B. Bull France
Bull France ralise le tiers du chiffre daffaire du groupe et emploie plus de 6000 personnes.
Cest un intgrateur de technologies qui fournit des solutions adaptes aux besoins de chaque client,
en utilisant loffre de produits et de services de BULL, associe loffre et aux comptences des
meilleurs partenaires. Le Groupe Bull a adopt une stratgie dindpendance vis--vis du
gouvernement et a conclu des alliances dans le monde entier.
Aprs un dveloppement aussi rapide, une restructuration a dbut en 1994 qui a impliqu la
fermeture de plusieurs usines de fabrication dont lactivit avait t rduite. Lactivit de Bull sest
progressivement concentre sur les tches dintgration. Les mesures prises afin de rduire les cots
avaient pour but de permettre la compagnie de retourner dans le secteur priv, ce qui se fait depuis
1994, avec comme principaux actionnaires de dpart France Tlcom, NEC et Motorola.

Date: 27/06/00
Page:8/46
Olivier Schmitt
Yannik Soubigou
C. Le service Consulting et Systmes dIntgration

Le service CSI emploie 4000 personnes dans 374 agences dans le monde et recrute 1100 experts par
an. CSI France ralise un chiffre daffaire de 2 milliards de francs et fournit des services dans les
diffrents ples de comptence suivants :
E-Solutions
Administration et Scurit
Architecture et Information
Formation
Applications Consulting
Le service CSI ( Consulting et Intgration de Systmes ) est trs rcent. Il a t cr dans le but de
construire des systmes dinformations qui rpondent le mieux possible aux attentes des clients. Leur
but tant dutiliser un capital d'exprience et d'expertises afin daboutir une offre personnalise
couvrant les domaines dcisifs du systme dinformation. Ce service bnficie dune implantation
rgionale et europenne au plus prs des clients. En effet, le service CSI est reprsent dans les villes
franaises indiques sur la carte suivante, avec deux centres dexpertise europens : Paris et
Grenoble.
Lille
Caen
Rennes
Nantes
Paris Metz
Nancy
Strasbourg
Tours
Poitiers
Bordeaux
Lyon
k Grenoble
Montpellier Nice
Toulouse
Marseille
Le service CSI pourra ainsi conseiller le client afin danticiper les choix dvolution, conduire et
dployer les projets d'envergure et fournir des expertises multiples dans la dure.

Date: 27/06/00
Page:9/46
Olivier Schmitt
Yannik Soubigou
V. Etude bibliographique
Pendant la partie mi-temps du stage, de dbut janvier fin fvrier, nous avons recherch les meilleurs
outils et cherch faire les meilleurs choix dimplmentation pour notre Proxy.
A. LDAP et les annuaires
Les annuaires (Recommandation X.500 parue en 1994 de l'UIT-T connue aussi comme ISO/IEC
9594 : Technologie de l'information Interconnexion des systmes ouverts Annuaire) permettent
de grer de faon centralise les donnes de lentreprise concernant les personnes, leurs habilitations,
la configuration des logiciels, des donnes lies larchitecture du rseau, les machines... La
dfinition de cette norme dannuaires a t labore l'origine pour traiter la gestion des adresses
lectroniques, de concert avec l'application du traitement des messages lectroniques d'ISO (X.400).
Le protocole daccs et de requtes ces annuaires a t nomm DAP (Directory Access Protocole)
et utilisait larchitecture couches dISO. Ce protocole a t abandonn et remplac par le protocole
LDAP (Lightweight Directory Access Protocole) pour les accs par des clients Internet, LDAP
fonctionnant au-dessus de IP et de TCP et tant beaucoup plus simple implmenter et utiliser sur
Internet. La version 2 de ce protocole (RFC 1777 parue en 1995) est trs largement supporte et la
version 3 (RFC 2251 parue en 1997) tend aujourdhui devenir le standard daccs aux annuaires sur
Internet.
Les annuaires X.500
Modle de donnes
Un annuaire X500 est une collection d'informations de toutes catgories. Ces informations sont
stockes dans la "Directory Information Base" ou DIB. La DIB est compose d'entres. Ces entres
sont constitues de un ou plusieurs attributs qui peuvent prendre une ou plusieurs valeurs.
Structure
Les entres de la DIB sont organises hirarchiquement, sous forme d'un arbre, le DIT ou Directory
Information Tree. Ce DIT contient donc deux types dentres :
Les nuds qui sont des entres part entire, et sont la base d'un sous-arbre du DIT.
Les feuilles qui terminent les branches des sous-arbres.
Chaque entre de larbre est nomme par un nom tenant compte du chemin parcouru dans l'arbre
pour l'atteindre, depuis la racine. Il existe deux appellations pour ces entres :
Le nom distinctif relatif (RDN ou Relative Distinguished Name).
Le nom distinctif (dn ou Distinguished Name ), concatenation des diffrents RDNs du chemin
utilis depuis la racine, pour joindre lentre concerne.

Date: 27/06/00
Page:10/46
Olivier Schmitt
Yannik Soubigou
Construction dun Distinguished Name
B. Le protocole LDAP
LDAP (Lightweight Directory Access Protocol) est le protocole daccs aux annuaires LDAP. Il
permet de passer des requtes un serveur dannuaire et de retourner les rsultats aux clients. Ce
protocole fonctionne au-dessus de la couche TCP et le port dcoute standard des serveurs LDAP est
le port 389.
La version 2 parue en 1995 dfinissait les types de messages (verbes ) suivants :
SearchRequest et SearchResponse : pour chercher des entres suivant un filtre.
ModifyRequest et ModifyResponse : pour modifier les attributs dune entre.
AddRequest et AddResponse : pour ajouter une entre.
DelRequest et DelResponse : pour effacer une entre.
ModifyDNRequest et ModifyDNResponse : pour modifier le DN dune entre.
CompareRequest et CompareResponse : pour comparer des valeurs dattributs avec des
valeurs donnes.
BindRequest et BindResponse : pour dbuter une connexion LDAP.
AbandonRequest : pour demander au serveur dabandonner la requte en cours.
UnbindRequest : pour finir une connexion LDAP.

Date: 27/06/00
Page:11/46
Olivier Schmitt
Yannik Soubigou
Les principales modifications apportes par la version 3, apparue en 1997 sont :

Support complet de LDAPv2.
Apparition dun mcanisme de referral (cf. la partie V.C. Les referrals de LDAPv3).
Possibilit dutiliser les mcanismes SASL (Secured Authentification Socket Layer).
Le protocole peut tre tendu pour de nouvelles oprations.
Les nouveaux verbes apports par la version 3 sont :
SearchResultEntry, SearchResultDone et SearchResultReferral : compltent SearchResponse.
ExtendedRequest et ExtendedResponse.
Les messages peuvent aussi tre tendus par un champ controls situ en fin de message et qui peut
tre interprt par le serveur dannuaire pour que celui-ci adopte un comportement spcifique.
Nous nous sommes familiariss avec ces notions en lisant les RFC 1777 (LDAPv2) et 2251
(LDAPv3) et en manipulant lannuaire Netscape Directory Server 4.1
C. Lencodage BER de la grammaire ASN1 de LDAP
La grammaire telle que dcrite dans lannexe A spcifie le protocole LDAPv3 suivant les rgles
ASN1 (Abstract Syntax Notation 1).
Les messages LDAP sont alors cods pour transmission sur le rseau suivant les rgles dencodage
BER (Basic Encoding Rules). Les diffrents lments de la grammaire ASN1 prennent des valeurs
hexadcimales prcises et les chanes de caractres comme les entiers sont cods tels quels.
Un module de dcodage dlment BER est donc ncessaire la rcupration de messages LDAP.
D. Les referrals de LDAPv3
Linformation que contient un annuaire est parfois partage entre plusieurs DIT. Dans ce cas, une
information est ajoute sur larbre indiquant que le sous arbre en question se trouve sur un autre DIT.
Ladresse du nouveau DIT et lendroit de larbre o lon peut trouver cette information sont codes
sous forme dURL.
Un exemple dURL LDAP :
ldap://aladin4.frec.bull.fr:1389/ou=bull,o=unedic.fr??base?
Elle signifie quil faut sadresser au serveur se trouvant sur la machine aladin4.frec.bull.fr et coutant
sur le port 1389. Le Distinguished Name de cette entre est ou=bull, o=unedic.fr .
LDAPv3 permet au serveur de transmettre cette information aux clients. Ce mcanisme est appel
referral. Quand un client LDAPv3 met une requte concernant une information qui ne se trouve pas
dans lannuaire concern, il se voit retourner un avis de referral vers un second annuaire (annuaire
dlgu ). Il sait alors quil peut trouver linformation quil veut en expdiant la mme requte
lannuaire dlgu.
Ce mcanisme permet de sous-traiter (dlguer) des branches de larborescence de lannuaire un
autre serveur dannuaire distant.

Date: 27/06/00
Page:12/46
Olivier Schmitt
Yannik Soubigou
E. Proxy LDAP et cahier des charges

1. Proxy LDAP
Le but principal dun Proxy est dajouter des fonctionnalits la relation client/serveur sans avoir
toucher au serveur souvent dj lourd ni aux clients qui sont trop nombreux pour en envisager une
modification.
Quelques exemples de fonctionnalits :
La gestion de cache :
Le proxy intercepte les requtes du client et garde en mmoire les rsultats associs aux dernires
requtes traites. Sil reoit une requte quil a encore en mmoire, il retourne directement le
rsultat au client sans sadresser au serveur.
Le routage :
Le proxy peut adresser les requtes du client un serveur parmi plusieurs aprs analyse de la
requte. Le Proxy constitue, pour les clients, un unique point dentre un service.
Le filtrage :
Le Proxy peut refuser de transmettre au serveur des requtes de clients non autoriss ou des types
de requtes interdits. Il peut aussi filtrer les rsultats retourns par le serveur.
Un Proxy LDAP est donc une application place entre le client et le serveur qui analysera les
messages LDAP transitant entre eux. Il pourra agir sur ces messages suivant les fonctionnalits qui
lui sont donnes.
2. Cahier des charges
Fonctionnalits de bases :
Le Proxy doit possder toutes les fonctionnalits de base que doit possder un Proxy. Ctait le but de
notre premire partie de stage : dvelopper un Proxy qui transmette dun sens comme de lautre les
messages LDAP aprs en avoir dcod et analys les informations.
Nous devions dvelopper une application performante, modulaire et pouvant servir plusieurs clients
sans perte majeure de performance.
Temps de traitement des requtes :
Le temps de traitement des requtes par le Proxy ne doit pas tre trop important. Dans toutes les
utilisations futures et possibles du logiciel, une attention particulire sera porte la rapidit de
traitement des requtes des clients.
Rsistance une charge leve :
Tout Proxy doit tre prt subir une demande de connexions trs importante. Celui-ci ne doit donc
pas montrer de perte de performance trop importante sil doit traiter un nombre important de
connexions clientes.
Les contraintes de prix taient importantes aussi. Nous devions raliser notre proxy en nengageant
que trs peu de frais.
Fonctionnalits supplmentaires :

Date: 27/06/00
Page:13/46
Olivier Schmitt
Yannik Soubigou
Jusquau mois davril, la principale fonctionnalit que devait prsenter le Proxy portait sur la
scurit.
La gestion des droits des clients sur les entres de lannuaire est souvent faite par le serveur luimme. Cependant, ce type de gestion propritaire a ses limitations. Nous devions donc ajouter au
Proxy un module qui identifierait les clients et leur affecterait des droits suivant une base de donnes
stocke dans un annuaire. Le Proxy transmettrait alors uniquement les messages dun client aprs
vrification de ses droits.
A la fin du mois davril, suite au dcs de Marc Fleurisson, nous avons parl du futur de notre stage
avec Jrme Camilleri, Antoine Geronimi et Thierry Dessenne. Lajout de cette fonctionnalit a alors
du tre abandonne au profit dune gestion des referrals au niveau du Proxy. En effet, personne ne
pouvait plus nous aider sur cette partie et lajout de la gestion des referrals intressait directement
Antoine Geronimi et Thierry Dessenne dans le cadre de leur projet.
Beaucoup de client LDAPv2, ne comprenant pas les referrals, sont encore utiliss aujourdhui. La
fonctionnalit que nous devions ajouter au Proxy permettrait de rendre la prsence de referrals
invisible pour les clients.
Quand celui-ci reoit un avis de referral, il doit traduire lURL qui lui est transmise, ouvrir une
connexion vers lannuaire dlgu, lui transmettre la requte et transmettre la ou les rponses au
client aprs avoir ferm la connexion avec le deuxime annuaire. Le tout doit tre cach au client.
F. Les Outils tudis

1.
LAPI JNDI de Sun (Java Naming and Directory Interface)
Au dbut du stage, et en accord avec notre sujet initial, nous avons ax notre recherche sur des outils
Java, et plus particulirement JNDI(java Naming and Directory Interface). En effet, Marc Fleurisson
nous avait orient vers JNDI parce que cette interface tait utilise avec succs dans le projet
WebD&CA pour interroger un annuaire LDAP. La technologie Java nous a aussi sembl intressante
car un proxy est un logiciel qui doit communiquer sur le rseau et que Java est bien adapt pour cette
tche. De plus, profiter de fonctionnalits comme le garbage collector nous paraissait intressant.
Nanmoins, le problme des performances risquait de se poser, surtout pour un proxy, qui par
essence doit rpondre rapidement.
Cette API est de trs haut niveau et permet donc de dvelopper rapidement des clients LDAP. Elle
fonctionne de faon modulaire. Le module JNDI en lui-mme noffre que peu de fonctionnalits mais
il permet de fdrer sous une interface unique toutes les interfaces qui offrent des services de
nommage ou dannuaire. En effet, un module LDAP, DNS ou encore NIS (ces modules sont appels
Service Provider) peuvent se brancher dans le module JNDI pour offrir des services spcifiques pour
les protocoles respectifs. Pour plus de dtails, on se reportera lurl suivante :
http://www.java.sun.com/products/jndi/
Pour nous familiariser avec cette API nous avons dvelopp un petit client java qui se connecte un
annuaire en sauthentifiant grce un nom et un mot de passe et qui passe une requte de type

Date: 27/06/00
Page:14/46
Olivier Schmitt
Yannik Soubigou
LdapSearch selon un filtre sur les attributs dune (ou des) entre(s) de lannuaire. Ce client traite
ensuite les rsultats retourns et les prsente lutilisateur.
Ce programme nous a permis de nous rendre compte que lAPI JNDI et son Service Provider LDAP
ne permettent que de faire des requtes et de traiter les rsultats. Cest seulement une API cliente qui,
comme JDBC, passe des requtes un serveur et traite les rsultats. Nous ne pouvions donc pas
utiliser cette interface pour notre proxy car celui-ci doit pouvoir jouer le rle de serveur : il doit
savoir interprter une requte qui arrive et gnrer des rsultats. Nous avons donc ensuite cherch
dautres API en Java qui offrent des fonctionnalits serveur.
2. Netscape Directory SDK 4.0 for Java
Cette API dite par Netcape fourni des primitives Java pour adresser des requtes un annuaire
LDAP et traiter les rsultats. Elle offre globalement les mmes fonctionnalits que le JNDI ( client
uniquement ) et son Service Provider LDAP, en plus dtre spcialement optimise pour sinterfacer
avec lannuaire LDAP de la mme socit : le Netscape Directory Server 4.1
Pour plus de dtails on se reportera :
http://developer.netscape.com/software/sdks/index.html?content=/tech/directory/downloads.html
3. Netscape Directory SDK 4.0 for C
Cette API dite par Netcape fourni des primitives C pour adresser des requtes un annuaire LDAP
et traiter les rsultats. Elle offre globalement les mmes fonctionnalits que lAPI prcdente (client
uniquement) et est spcialement optimise pour sinterfacer avec lannuaire LDAP de Netscape.
Pour plus de dtails on se reportera :
http://developer.netscape.com/software/sdks/index.html?content=/tech/directory/downloads.html
4. Loutil Snacc4Java dIBM
Loutil Snacc4Java (Snacc for Java) est dit par le dpartement Alphaworks dIBM qui effectue
diffrents travaux exploratoires dans diffrents domaines de la technologie. Ce produit effectue trs
bien la tche pour laquelle il a t conu mais il ne constitue pas encore un produit commercial. Il
faut plus le voir comme un dmonstrateur de technologie.
Snacc est un gnrateur danalyseur de grammaire ASN1 en Java. Il suffit de lui fournir en entre la
grammaire ASN1 de LDAPv3 dans notre cas pour quil produise un ensemble de classes Java qui
analysent et dcodent cette grammaire. Cet outil offre des services beaucoup plus puissants que le
JNDI puisque cest un outil client et serveur : il permet denvoyer des requtes et de traiter les
rsultats mais aussi de recevoir des requtes et denvoyer des rsultats. Ce produit fourni un support
complet de la grammaire LDAP.
Un petit serveur LDAP a mme t dvelopp par Clayton Donley en utilisant cette interface. Pour
plus de dtails sur son travail, on se reportera : http://www.linc-dev.com/
Cet outil sest rvl tre un bon candidat pour notre proxy et cest donc pourquoi nous avons ralis
une maquette (une toute premire version simplifie) de notre proxy en utilisant cette interface, qui a

Date: 27/06/00
Page:15/46
Olivier Schmitt
Yannik Soubigou
bien rempli son rle. Nanmoins, nous navons pas continu dans cette voie pour des raisons de
performance et de non-disponibilit commerciale officielle de cette API.
Pour plus de dtails, on se reportera : http://www.alphaworks.ibm.com/tech/snaccforjava
5. Le couple Cup/Jlex
Notre proxy devant analyser la grammaire ASN1 et LDAP pour dcoder les messages mis par un
client, nous avons envisag un moment de trouver des outils danalyse grammaticale analogues aux
clbres Yacc et Lex. Comme nous tions dans notre optique de dveloppement en Java, nous avons
trouv les outils Cup et Jlex qui sont respectivement un gnrateur de reconnaisseur de grammaire et
un analyseur lexical. Ces deux outils auraient pu nous permettre, moyennant une rcriture de la
grammaire LDAP au format reconnu par ces outils, de gnrer un ensemble de classes reconnaissant
cette grammaire. Mais il nous aurait quand mme manqu un moteur dencodage et de dcodage
ASN1. Nous navons donc pas pouss plus loin cette recherche.
Pour plus de dtails, on se reportera aux rfrences suivantes :
http://www.cs.princeton.edu/~appel/modern/java/CUP/
http://www.cs.princeton.edu/~appel/modern/java/JLex/
6. Les outils dOSS Nokalva
La compagnie amricaine OSS Nokalva, rpute pour son expertise en ASN1, dite des API clientes
et serveur pour manipuler des messages ASN1. Ces outils de grande qualit sont disponibles pour de
nombreux langages de programmation, et sur de nombreuses plates-formes. Mais ces produits sont
commerciaux et leur prix est lev.
Lun des objectifs de notre stage tait de produire un proxy qui nimplique que peu de frais. Nous
avons donc renonc utiliser ces outils. Pour plus de dtails, on se reportera :
http://www.oss.com/products/products.html
7. Les outils fournis par les chercheurs de luniversit du Michigan
Les chercheurs et tudiants de luniversit du Michigan ont t pour une bonne partie lorigine des
travaux qui ont conduit aux normes dannuaires LDAP actuelles. Leurs travaux font rfrence dans le
monde entier et ils continuent aujourdhui de dvelopper des logiciels utilisant LDAP et les annuaires
X500.
Lintrt principal de ces logiciels est quils sont gratuits et pour la plus grande partie le code source
de ces logiciels est librement accessible. Aujourdhui, ils continuent de dvelopper des logiciels
client LDAP et des serveurs mais cette activit semble devoir sarrter bientt. Elle nest plus aussi
importante quil y a quelques annes. Ces travaux ont t repris par la communaut de dveloppeurs
OpenLDAP qui eux, travaillent amliorer des produits gratuits et dont le code source est accessible
librement.
Pour plus de dtails, on se reportera : http://www.umich.edu/~dirsvcs/

Date: 27/06/00
Page:16/46
Olivier Schmitt
Yannik Soubigou
8. Les outils fournis par le groupe OpenLDAP
OpenLDAP est une communaut de dveloppeurs issus du monde entier et qui travaillent ensemble
pour dvelopper une suite dapplications (clientes et serveurs) et doutils de dveloppement lis
LDAP qui soient robustes, de niveau commercial et dont le code source soit disponible. Ce package
est bas sur la version 3.3 Release de lUniversit du Michigan.
Ces outils, clients et serveurs sont programms en langage C et fournis gratuitement sous forme de
package. Nous avons utilis une partie des librairies de ce package dans sa version 1.2.7 disponible
depuis fvrier 2000 pour programmer notre proxy. La version 1.2.10 de ce package est actuellement
(en juin 2000) la dernire version disponible.
Nous avons utilis la librairie de codage et de dcodage BER (ASN1 Basic Encoding Rules) de ce
package et nous lavons compltement dtache (en prenant juste les fichiers ncessaires une bonne
compilation) du package pour lincorporer dans notre proxy.
Cette approche a des avantages, dont lespoir de performances (programmation en langage C), la
gratuit et la disponibilit des fichiers source du produit. Mais elle a aussi des inconvnients dont le
fait que les fichiers source soient trs peu comments et assez complexes et aussi le fait que nous ne
soyons pas certains que le codage et dcodage BER soit complet et dbogu.
Pour plus de dtails, on se reportera : http://www.openldap.org
9. Les proxy LDAP disponibles sur le march
Innosoft LDAP Proxy Server :

Ce proxy est ce jour lun des proxy LDAP commerciaux les plus rputs. Il offre les fonctionnalits
complmentaires suivantes : quilibrage de charge entre serveurs rpliqus, configuration fine du
filtrage, filtrage des domaines et des adresses IP, filtrage des verbes, rcriture des rsultats, et
prvention des attaques de type dni de service et tlchargement complet de lannuaire .
http://www.innosoft.com/directory_solutions/ilps-descript.html
MaXware LDAP Access Engine
Ce proxy appel fait partie de larchitecture Enterprise Meta Solution (EMS) et offre les
fonctionnalits complmentaires suivantes : gestion de plusieurs jeux de caractres, contrle daccs
et filtrage des attributs, limitation en temps ou en taille du rsultat des requtes, support de LDAP v2
et v3, rsolution des referrals et administration distante.
http://www.maxware.no/mias/
Nexor Directory Boundary Agent
Il est constitu de deux processus distincts : un qui value la connexion cliente en se basant sur son
adresse IP et port TCP, et lautre qui traite les requtes et effectue des vrifications au niveau du
protocole LDAP. Ce proxy est configurable : un module de contrle daccs permet de spcifier qui
peut accder quelles donnes, il permet aussi de cacher des branches de lannuaire, et un filtrage fin
des donnes est possible.
Ce proxy, dans le but de pouvoir fonctionner sur un FireWall a t test par un centre dvaluation et
a obtenu la certification ITSEC E3.
http://www.nexor.com/products/dba.htm
BullSoft Netwall 4.0 LDAP Proxy

Date: 27/06/00
Page:17/46
Olivier Schmitt
Yannik Soubigou
Un proxy LDAP a t dvelopp au sein de BullSoft en 1999. Ce proxy cod en langage C utilise un
moteur de codage et de dcodage fourni par OSS et sinspire de larchitecture du proxy DNS de
Netwall 4.0 : le dmon inetd instancie un processus pour chaque demande de connexion de clients.
Ce proxy offre comme fonctionnalit complmentaire la confirmation de lidentit du client en
effectuant une rsolution DNS simple et inverse du nom du client.
Ce proxy ne fait pas actuellement partie de loffre commerciale BullSoft de Netwall.
http://www.securware.com/netwall/
10. Les clients LDAP disponibles
Le Navigateur LDAPBrowzer
LDAPBrowzer est un client LDAP gratuit dvelopp en Java. Il permet la consultation, la
modification dun annuaire LDAP et limportation dentres dans lannuaire a partir de fichiers ldif.
Cest le client que nous avons utilis le plus souvent pour nos tests.
Nous avons dcouvert un Bug : il ne permet pas dajouter manuellement des entres.
http://www.iit.edu/~gawojar/ldap/
Visual LDAP
Cest un client que nous avons rcupr en version de dmonstration. Toutes les fonctionnalits
ntaient donc pas prsentes et il tait moins simple dutilisation que le prcdent.
http://www.CQSL.com
Directory Mark
Ce client, contrairement aux autres nest pas graphique. Il nous a particulirement servi tester les
performances de notre Proxy. En tant que BenchMark dannuaire, il donne des informations
intressantes sur les performances dun serveur dannuaire.
Il prend en entre un script qui lui permet de gnrer des requtes quil transmet alors au serveur. Sa
fonctionnalit la plus intressante est sa possibilit de simuler plusieurs clients qui se connectent
simultanment au serveur.
www.mindcraft.com

Date: 27/06/00
Page:18/46
Olivier Schmitt
Yannik Soubigou
Netscape Browser et Netscape AddressBook

Ce sont deux outils fournis avec Netscape Communicator.
Le Navigateur Netscape permet denvoyer des requtes LDAPSearch que lutilisateur entre sous
forme dURL. Il nous a principalement servi tester les filtres de recherche LDAP.
Le Carnet dAdresses Netscape permet la recherche dinformations dans un annuaire LDAP. Son
mode de fonctionnement diffrent nous a permis de tester plus profondment notre Proxy.
Netscape Directory Console
Cest la console dadministration du serveur dannuaire Netscape Directory Server. Elle permet la
consultation, la modification et ladministration dun annuaire.
Nous lavons utilis pour peupler et administrer notre serveur de tests.
Les commandes DOS fournies avec lannuaire Netscape
Elle permettent denvoyer laide de commandes DOS, des requtes LDAP de consultation et de
modification. On trouve les commandes suivantes : ldapdelete, ldapsearch, ldapmodify et ldapcmp.

Date: 27/06/00
Page:19/46
Olivier Schmitt
Yannik Soubigou
VI. Dveloppement
A. Phase prliminaire
Une fois que nous nous tions fixs sur les outils utiliser, en loccurrence les outils fournis par
OpenLDAP, nous avons men une tude prliminaire permettant de concevoir notre proxy.
1. Etude de larchitecture globale du logiciel
Il nous a t prsent un proxy ayant dj t dvelopp par BullSoft, sintgrant dans le produit
NetWall. Ce proxy a t dvelopp en C pour Unix (Aix) en utilisant un moteur de codage et de
dcodage des messages LDAP fourni par OSS. Ce proxy ne convenait donc pas ce que lon
souhaitait faire puisque la licence du module fourni par OSS est trs onreuse. De plus, ce proxy
navait pas t dvelopp de faon multithreade : un processus instance du proxy devant tre
dmarr chaque connexion dun client par le dmon inetd . Linstanciation dun processus tant
beaucoup plus longue que celle dun thread au sein dun processus, il nous a sembl quil serait
prfrable de dvelopper le ntre de faon multithread. Nous avons de plus pens dvelopper notre
proxy en langage C++ dans un soucis de clart et de facilit de dveloppement : nous pensons ici
toutes les fonctionnalits supplmentaires que le C++ apporte au C comme la surcharge doprateurs,
de constructeurs, de mthodes, lallocation dynamique et la gestion des flux. Il nous a t fourni par
Marc Fleurisson comme plate-forme de dveloppement le Visual C++ 5.0 de Microsoft sur des
machines PC sous Windows NT 4.0.
Une fois ces principaux choix faits, il nous restait choisir parmi les diffrentes API celles que nous
allions utiliser et nous former utiliser celles-ci pour raliser une premire version (une maquette)
du proxy. La principale motivation qui nous a guide pour ces choix fut lobjectif de portabilit
maximale du logiciel final sur une autre plate-forme (Unix en particulier).
Un de ces choix tait relatif la communication de notre proxy avec le rseau. Le protocole LDAP
tant conu pour fonctionner au-dessus de IP et de TCP, il nous fallait choisir parmi les diffrentes
librairies offrant le mcanisme de Socket. La librairie C standard de gestion des communications par
socket sous Windows est appele winsock. Elle comporte des mcanismes et des primitives socket
trs similaires ce que lon trouve sous Unix et elle apporte aussi des fonctionnalits supplmentaires
telles que la dtection dvnements rseau comme la fermeture distante de la connexion. La librairie
MFC (ou plutt architecture oriente objet de Microsoft) dfini aussi des classes permettant la
gestion de sockets. Ces classes apportent des fonctionnalits supplmentaires et permettent de
manipuler de faon objet les sockets. Notre objectif de portabilit maximale nous a amen
utiliser les mcanismes socket standards de winsock, qui seront facilement portable.
Un autre de ces choix tait relatif la gestion du caractre multithread de notre proxy. Trois librairies
permettent de grer des threads sous Windows. On trouve la librairie C standard, la lAPI Win32 et
larchitecture objets MFC. Nous navons pas utilis les classes de la librairie MFC car la gestion de
threads aurait t de cette faon trop diffrente de ce qui se fait sous Unix. La librairie standard C et
lAPI Win32 offrent presque le mme niveau de fonctionnalits et ressemblent fortement ce que
lon peut trouver sous Unix. Nous avons utilis lAPI Win32 pour notre proxy. Il ne sest pas agit l

Date: 27/06/00
Page:20/46
Olivier Schmitt
Yannik Soubigou
dun vrai choix car nous navons dcouvert lexistence des primitives multithread de la librairie C
qu la fin de notre projet.
Le proxy avait t initialement prvu pour apporter les valeurs ajoutes suivantes :
Simple proxy permettant de cacher larchitecture physique des annuaires
Gestion dun systme dhabilitations pour pouvoir sinterfacer avec WebD&CA (un logiciel de
consultation dannuaire LDAP et de dlgation dadministration dvelopp par BULL ) et
identifier les clients qui se connectent et leur affecter des droits daccs
Routage : Gestion des referrals pour pouvoir rsoudre les rfrences des donnes dannuaires
rparties mme si le client ne sait pas rsoudre les referrals.
Cache : gestion dune mmoire cache au sein du proxy pour acclrer laccs aux donnes par les
clients.
La fonctionnalit principale qui avait t prvue tait la gestion des habilitations. Suite une
rorientation de nos objectifs en cours de stage, il a t dcid dabandonner cette partie, en raison de
la complexit de la tche et du temps qui nous restait. Il a t dcid de dvelopper la gestion des
referrals en lieu et place des habilitations. Cest pourquoi nous avons dsactiv certaines parties du
programme en les mettant en commentaires et qui sont relatives la gestion des habilitations.
Les besoins que nous avons identifis taient :
Ncessit pour le thread principal de lapplication de faire toutes les initialisations ncessaires au
bon dmarrage du logiciel.
Prvoir un module charg de la configuration du proxy, soit par ligne de commande (et son
interprtation) soit par fichier de configuration (et sa lecture et son interprtation). Il nous a
sembl bon que ce module puisse gnrer automatiquement un fichier de configuration type au
cas o celui-ci ne soit pas trouv.
Ncessit dun module qui permette dassurer linterface console avec loprateur du proxy, ne
serait-ce que pour arrter le proxy proprement et passer quelques ordres de type statistique.
Ncessit de traiter les diffrentes transactions des clients en parallle et prvoir un algorithme
adapt de traitement des diffrents messages entre le proxy, le client et le serveur LDAP. Pour
cela, le module de traitement dun client doit pouvoir communiquer avec lannuaire tout
moment. Il ne faut pas que lenvoi dun message un client soit bloqu par le traitement des
messages dun autre client.
Il nous a sembl intressant de limiter le nombre de threads qui soient simultanment dans le
proxy. Ainsi, on pourra fixer une limite dans le fichier de configuration. Si un client cherche
accder au proxy un moment o le nombre maximal est dj atteint, il se verra rejeter sa
connexion. Il faudra quil essaye plus tard.
Ncessit davoir un module qui soit charg daccepter les demandes de connexions des
nouveaux clients (et de faire du filtrage si ncessaire). Lacceptation dune demande de
connexion par le proxy doit pouvoir se faire en parallle du traitement des clients dj en cours de
traitement et du traitement des ordres passs la console par loprateur.
Une fois ces modules bien identifis, nous avons rdig un document Spcifications
Fonctionnelles qui les regroupait. On trouvera dans la partie VI.C la description de la faon dont
nous avons architectur finalement ces fonctionnalits.

Date: 27/06/00
Page:21/46
Olivier Schmitt
Yannik Soubigou
2. Etude des librairies fournies par OpenLDAP
Nous nous sommes bass sur le package OpenLDAP 1.2.7 datant de fvrier 2000 pour raliser notre
proxy. Ce package est driv de la version 3.3 Release de lUniversit du Michigan. Celui ci
comprend :
Le code source de logiciels clients : fax500, finger, gopher, mail500, rcpt500 (X500 email query
responder), ldapdelete, ldapmodify, ldapmodrdn, ldapsearch, ud (interactive LDAP Directory
Server query program).
Des outils annexes : saucer (General purpose command-line LDAP client), des outils PHP3,
web500gw (HTTP to X.500/LDAP gateway), whois++, ldaptcl (extension to Tcl to interface with
an LDAP server).
Des documentations sous forme de fichier texte (readme) et de fichiers daide Unix (man).
Des librairies et leurs fichiers source : libavl, liblber, libldap, libldbm, libldif, liblthread, liblutil
Des serveurs et leurs fichiers sources : ldapd (dmon LDAP), slapd (serveur dannuaire), slurpd
(outil de rplication entre annuaires).
Tous les outils ncessaires la compilation : makefile sous Unix et dsp et dsw sous Windows
pour le Visual Studio.
Quelques outils de tests dont des fichiers ldif.
Les deux sources dinformation que nous avions disposition pour utiliser ces librairies sont les
fichiers man dcrivant les primitives des fichiers encode.c et decode.c ainsi que les sources des
serveurs et clients prsents ci dessus.
Notre premier programme avait pour but de rcuprer une requte LDAP mise par un client JNDI
(que nous avions dvelopp plus tt quand nous dcouvrions cette API Java).
OpendLDAP utilise les structures de donnes suivantes :
Un BerElement est une suite doctets cods sous forme hexadcimale. Les messages LDAP sont
stocks sous cette forme par lAPI OpenLDAP.
Un SockBuf est une structure dans laquelle peuvent tre stocks plusieurs message LDAP (sous
forme de BerElement).
Les primitives que nous avions disposition taient alors :
ber_get_next pour rcuprer un message LDAP sous forme de BerElement.
ber_get_tag et ber_skip_tag qui permettent de lire, un par un, les composants (tag ou tiquette )
dun message LDAP.
Ces primitives sont de trs bas niveau et ncessitent une connaissance parfaite du codage BER des
lments de la grammaire LDAP, connaissance que nous ne pouvions pas avoir, faute de donnes
suffisantes.
Aprs une lecture plus approfondie des sources des serveurs et clients nous avons remarqu que
lutilisation dune primitive de plus haut niveau (ber_scanf ) pourrait rendre le codage plus simple et
plus rapide.
Linterface fournie par OpenLDAP que nous allions utiliser tant alors de trs bas niveau
(codage/dcodage BER des messages LDAP) il nous a fallu dvelopper une interface de niveau
suprieur qui pourrait tre intgre dans le Proxy.
Cette nouvelle interface cachera aux couches suprieures le codage/dcodage des messages LDAP et
ceux-ci seront stocks sous forme dobjets C++, lutilisation en sera plus simple.

Date: 27/06/00
Page:22/46
Olivier Schmitt
Yannik Soubigou
B. Dveloppement dune interface LDAP

LAPI OpenLDAP nous fournissant des primitives de trop bas niveau (codage et dcodage BER), il
a t ncessaire de dvelopper une couche LDAP de niveau suprieur qui permette de manipuler des
messages LDAP de faon plus simple.
1. Structures de donnes
Pour une utilisation plus simple des donnes, nous avons dcid de stocker les informations
contenues dans les messages sous forme dobjet C++. Chaque lment du protocole LDAP dfini
dans la grammaire ASN1 (cf. Annexe A ) est donc un objet C++.
Par exemple, llment LDAPResult est un objet LDAPResult contenant les variables :
ResultCode : un entier.
MatchedDN : un pointeur vers un caractre.
ErrorMessage : un pointeur vers un caractre.
Referral : un pointeur vers un objet Referral.
Un message LDAP est un objet LDAPMess contenant alors toutes les informations ncessaires la
comprhension et la reconstruction du message.
Lobjet que manipuleront les couches suprieures cette interface est lobjet LDAPConnexion, qui
encapsule un objet LDAPMess et une connexion vers un serveur ou un client. Les mthodes de cette
classe sont :
SendLDAP : pour envoyer un message LDAP, stock sous forme dobjet LDAPMess, sur une
socket donne en paramtre.
RecvLDAP : pour recevoir dune socket donne en paramtre, un message qui sera stock sous
forme dobjet LDAPMess.
ImportLDAP : pour importer un objet LDAPMess dun objet LDAPConnexion un autre.
2. Choix darchitecture
Il existe un fichier source (de bind.cpp extended.cpp )pour chaque catgorie de verbes LDAP, un
ficher source (ldapv3.cpp ) pour lensemble des lments de la grammaire LDAPv3 autres que les
verbes ainsi quun fichier source concernant les exceptions (cf. ci-dessous).
La relecture et la modification sont alors facilites, le code tant plus clair.
3. Choix de conception
Les mthodes de classes

Lensemble des objets de la grammaire LDAPv3 possde les quatre mme mthodes :
Un constructeur, prenant un BerElement en argument ( pour recevoir un message).
Un destructeur.

Date: 27/06/00
Page:23/46
Olivier Schmitt
Yannik Soubigou
Une mthode print pour laffichage des messages LDAP.

Une mthode permettant de construire un BerElement (pour envoyer un message).
Ainsi, la classe BindRequest contient les mthodes suivantes :
Le constructeur BindRequest (BerElement *ber)
Le destructeur ~BindRequest
La mthode print(int incr) (largument incr permet lindentation pendant laffichage).
La mthode BuildBindRequest(BerElement *ber) qui retourne un BerElement.
Les exceptions
Il se peut que le client mette des messages errons, ne respectant pas le protocole. Dans ce cas,
les messages reus ne peuvent tre lus correctement. Quand un tel cas se prsente, une exception
est leve. Elle doit tre rcupre par les couches suprieures pour tre traite.
Le traitement dpend de la gravit de lerreur. Si le Proxy a pu lire le verbe LDAP de la requte
du client, il retourne au client un message lui signalant que sa dernire requte ne respecte pas le
protocole, sinon, il doit fermer la connexion.
Des exceptions de deux types peuvent alors tre leves suivant la conduite tenir.
LDAPConnexion et LDAPMess
Les objets LDAPConnexion et LDAPMess ont t dvelopps de telle sorte quune rutilisation de
cette interface soit possible pour le dveloppement dune application autre quun Proxy (i.e. un
serveur LDAP ou un client LDAP ). Un objet LDAPConnexion encapsule un unique message
LDAP et une unique connexion.
Dans le cas o louverture dune nouvelle connexion, vers un annuaire rfr (cf. VI.E Gestion de
la rsolution des referrals) par exemple, est ncessaire, il suffit de crer un nouvel objet
LDAPConnexion en appelant le constructeur avec la nouvelle socket en paramtre.
Les objets LDAPConnexion sont donc indpendants les uns des autres. La primitive importLDAP
permet lchange dinformations entre deux connexions.
Schma de fonctionnement de linterface LDAP

Date: 27/06/00
Page:24/46
Olivier Schmitt
Yannik Soubigou
C. Architecture globale du proxy

Suite aux besoins qui ont t exprims (cf. la partie VI.A.1), voici comment nous avons conu notre
proxy LDAP :
Ci dessous un schma de larchitecture globale du logiciel.
Le Proxy a t dvelopp comme une application Win32 avec utilisation de la console (fentre
DOS). Le proxy est dmarr par un oprateur en tapant au clavier dans une fentre DOS le nom du
programme. Aucun paramtre de dmarrage nest requis, toute la configuration du proxy est lue
partir dun fichier texte de configuration. Cette configuration, ainsi que dautres informations sont
ranges en mmoire globale partage (heap), accessible par tous les threads.
Une fois le proxy dmarr et le thread gestionnaire de connexions lanc, le thread principal joue le
rle dinterface avec ladministrateur du proxy, notamment pour permettre larrt du proxy. Il permet
aussi dafficher des informations concernant le fonctionnement courant du proxy et des statistiques.
Le module principal du proxy est constitu dune collection de fonction C dont la fonction main
sexcutant au sein du principal thread de lapplication. Les principales responsabilits de ce module
sont :
Chargement de la configuration de dmarrage

Date: 27/06/00
Page:25/46
Olivier Schmitt
Yannik Soubigou
Cration des structures de donnes globales et partages

Dmarrage du thread gestionnaire de connexions pour les clients
Gestion dune interface console avec loprateur du proxy
Arrt final du proxy
Le proxy LDAP tel que nous lavons conu est configurable par lintermdiaire dun fichier de
configuration. Ce fichier est au format texte et doit se trouver dans le rpertoire de travail (le mme
repertoire que lexcutable ou dans le PATH). Si le proxy ne trouve pas le fichier de configuration, le
proxy gnre automatiquement dans le repertoire courant un fichier de configuration type. Il ny aura
plus qu adapter ce fichier pour ses besoins. Loption fichier de configuration a t prfre
loption ligne de commande en raison du nombre de paramtres ncessaires.
Le thread gestionnaire de connexions a pour rle dattendre larrive de nouvelles connexions de
clients, de les accepter et de dmarrer un thread qui traitera leurs requtes. Il utilise pour cela une
socket en mode serveur et cre des sockets clientes attribues aux clients. Cette socket cliente est
passe en paramtre au thread charg du client qui cre une socket de connexion lannuaire. Chacun
des threads-clients possde donc au moins deux sockets de connexion : une vers le client et une autre
vers lannuaire. Une autre socket de connexion vers un autre annuaire pourra ventuellement tre
ouverte en cas de d-rfrencement dun referral . Le module gestionnaire de connexions est conu
de faon trs simple sous forme dune classe. Le module principal du proxy instancie une fois et une
seule en crant un objet de la classe HandlerCx .
Ci dessous un diagramme de squence
reprsentant un cas de fonctionnement courant du proxy,
en liaison avec le client et lannuaire

Date: 27/06/00
Page:26/46
Olivier Schmitt
Yannik Soubigou
Nous avons prouv la ncessit de conserver en mmoire un certain nombre dinformations

concernant les clients dont les requtes sont en train dtre traites. Pour cela, nous avons dfini une
classe ClientPool comme variable globale et qui permet de stocker toutes les informations
relatives aux diffrents clients qui sexcutent au sein du proxy.
Cet objet est donc une base de connaissance des clients en cours de traitement. La taille de
lensemble associ est gale au paramtre de configuration permettant de contrler (limiter) le
nombre maximum de threads de clients prsents un instant donn dans le proxy. Cette
fonctionnalit permet dviter de faire saturer le serveur hbergeant le proxy en lui vitant de lancer
une infinit de threads. Cette structure peut tre parcourue pour y rechercher des informations sur un
thread courant.
Les lments de cet ensemble sont des objets de classe ClientInfo et qui regroupent des
informations varies : un handle de thread permettant de contrler le thread du client, un pointeur
vers lobjet client qui regroupe les autres informations concernant le client, le dernier identificateur
de message pass, le dernier identificateur de protocole pour le dernier message envoy et la version
LDAP supporte par le client. On y mmorise aussi le message de dbut de connexion et qui permet
didentifier le client. On peut ainsi mmoriser ce dont on a besoin pour arrter un thread, fermer son
handle (noyau NT) et dtruire lobjet client, fermer les sockets ouvertes...
Cette structure est globale et partage : elle est cre par le thread principal, remplie par le thread
gestionnaire de connexions, et vide lorsquun thread se termine de faon naturelle ou larrt du
proxy. Cette structure est protge contre les accs concurrents des diffrents threads par un mutex
(mutual exclusion). En effet, lors de la connexion dun client, un objet de classe ClientInfo est cr et
ses variables sont affectes. Mais durant cette phase de cration du client, la structure clientpool se
trouve momentanment dans un tat instable. La partie de code concerne constitue une section
critique. Si cette partie de code ntait pas protge par un mutex, une erreur pourrait survenir si un
autre thread faisait un parcours de la structure clientpool (par lappel une mthode print, rechercher
ou ajouter). La ralisation de cette exclusion mutuelle fait appel un objet systme de lAPI Win32 :
lobjet mutex.
D. Algorithme de traitement des messages

Comme cest expliqu dans la RFC 2251 (dfinition du protocole LDAPv3), les changes de
messages LDAP entre un client et un annuaire ne sont pas synchrones. Il faut bien comprendre que
lalgorithme naf de proxy LDAP suivant est faux :
Attendre une requte du client
Lenvoyer lannuaire
Attendre le(s) rsultat(s) de lannuaire
Transmettre le(s) rsultat(s) au client
Recommencer
Un client peut tout moment dcider par exemple denvoyer un message abandon lannuaire et
un annuaire peut tout moment envoyer des messages non sollicits au client. Nous avons donc
dvelopp un algorithme asynchrone utilisant linstruction select() lie aux communications par
socket permettant de dterminer si des donnes sont arrives sur une connexion socket. Linstruction

Date: 27/06/00
Page:27/46
Olivier Schmitt
Yannik Soubigou
select permet de dtecter (durant une priode de temps donne limite par un dlai timeout ) un
vnement se produisant sur un ensemble de sockets. Cet vnement peut tre :
La socket devient prte en lecture (des donnes sont arrives)
La socket devient prte en criture
La socket est en erreur
Nous dtectons ainsi larrive dun message sur une connexion : le traitement consiste le plus souvent
lenvoyer lautre connexion. On change ainsi les messages arrivant entre le client, le proxy et
lannuaire.
reprsentant un cas de fonctionnement standard
lors dune transaction avec un seul client LDAP
On voit sur ce diagramme diffrents types de messages (ou verbes) faisant partie de la grammaire
LDAP. Comme dit prcdemment, le client peut envoyer un message AbandonRequest tout
moment et la dtection darrive de donnes sur un port de communication prend tout son sens.
E. Gestion de la rsolution des referrals
Comme nous lavons expliqu, un referral est un type de message LDAPv3 qui peut tre retourn au
client par lannuaire si celui-ci na pas la connaissance des donnes recherches. Inclure dans notre
proxy un module de traitement des referrals constitue une vraie valeur ajoute.
Lors de la rception dun referral par le proxy, plusieurs choix soffrent nous. Il sagit ici dune
politique de gestion des referrals. Une variable de notre fichier de configuration permet de fixer la
faon dont les referrals seront traits par le proxy.

Olivier Schmitt
Yannik Soubigou
DROP : le referral nest pas

transmis au client (il est pass
sous silence par le proxy),
REFERRAL : le referral est

transmis au client pour
traitement par le client,
CHAINING : le proxy suit le

referral pour trouver les
donnes
manquantes
et
retourner le rsultat au client.
Date: 27/06/00
Page:28/46

Date: 27/06/00
Page:29/46
Olivier Schmitt
Yannik Soubigou
MULTICASTING(non
implment) :
le
proxy
contacte tous les annuaires
connus pour trouver les
donnes
manquantes.
Le
contact de tous ces annuaires
doit se faire en parallle et le
premier annuaire rpondre
correctement (avec les donnes
recherches) est celui dont les
rsultats sont transmis au client
Ces quatre rgles sont prvues par la norme X500 (normalisations 88 et 93) et sont dtailles lurl
suivante : http://www.spidernet.tm.fr/
reprsentant un cas de fonctionnement standard
lors du traitement de type CHAINING dun referral

Date: 27/06/00
Page:30/46
Olivier Schmitt
Yannik Soubigou
La rsolution des referrals que nous avons implmente est complte car nous pouvons rsoudre tous
les referrals contenus dans un message LDAP et nous pouvons aussi rsoudre une succession de
referrals envoys dans des messages LDAP spars. De plus, notre algorithme permet de rsoudre
des referrals successifs, dans le cas o linformation rfre contient elle-mme des referrals. La
profondeur de rsolution de referrals ainsi chans est de plus paramtrable.
Les rsultats ainsi retourns au clients sont complets et tout se passe de faon transparente pour lui.
Notre proxy simule ainsi pour le client la prsence dun annuaire LDAP qui contienne lensemble des
informations recherches. Lobjectif de consolidation est atteint.

Date: 27/06/00
Page:31/46
Olivier Schmitt
Yannik Soubigou
VII. Tests et validation

A. Tests et validation
Les diffrents tests effectus ont t :
1. Les tests de conformit
Il a fallu couvrir de faon exhaustive tous les lments de la grammaire LDAP (v2 et v3).
Ces tests ont t principalement effectus laide du Navigateur LDAP LDAPBrowser (client en
Java)
Nous avons aussi dvelopp une interface html pour tester les filtres. Cette interface fonctionne
avec le navigateur Netscape (qui sappuie sur lAPI dannuaire de Netscape NSDK) qui lit des
LDAPURL et affiche le rsultat sous forme dune page web. Nous avons ainsi pu tester tous les
types de filtres lors dune requte ldapsearch.
Nous avons utilis DirectoryMark pour tester les diffrents lments de la grammaire LDAP. Ce
programme permet de tester les annuaires en leur envoyant de nombreuses requtes et ainsi de
gnrer un rapport de performance de lannuaire.
Parmi les lments de la grammaire LDAPv3, les verbes ExtendedRequest et
ExtendedResponse ainsi que llment ExtensibleMatch nont pas t tests faute de clients les
traitant.
Les tests que nous avons effectus lont t en utilisant principalement lannuaire Netscape Directory
Server 4.1. Nous avons aussi fait quelques tests beaucoup plus sommaires en utilisant le Global
Directory Server 3.0 dIsocor. Un bug a t constat concernant lutilisation conjointe du GDS v2.1
et v3.0, du proxy et de requtes contenant des contrles optionnels. Ce bug est dtaill la section
Amliorations et Bugs.
2. Les tests de stress
Laccs au Proxy par un nombre lev de clients et lenvoi dun nombre lev de requtes clientes
ont t simuls et observs. La plupart des pertes en temps cres par le Proxy sont dues la gestion
des sockets. De tels tests permettent dobserver le comportement du proxy en cas de pic de charge.
Deux types de dysfonctionnement peuvent dans ce cas arriver :
Les connexions des clients arrivent dans un intervalle de temps trs court.
Une socket serveur traite les demandes de connexion une par une et stocke les demandes en
attente dans une file dattente. Celle-ci tant de taille limite, il se peut quun client ne puisse pas
se mettre en attente. Il se passe alors ce que lon appelle du denial of Service : le client se voit
refuser la connexion.
Les connexions des clients arrivent dans un intervalle de temps moins court et le proxy a le temps
de toutes les traiter : la connexion du client peut tre rejete si lon atteint le nombre maximum de
threads dans le proxy.

Date: 27/06/00
Page:32/46
Olivier Schmitt
Yannik Soubigou
Ces tests ont t raliss :

En utilisant DirectoryMark : il permet de simuler un grand nombre de requtes provenant de
clients. Pour crer un script contenant de nombreuses requtes on utilise un script perl qui gnre
un fichier de test concernant 1000 entres.
Ces scripts ont permis de tester de nombreuses requtes de types diffrent.
Le proxy a bien ragi ces tests de stress, nous navons pas remarqu de ralentissement spcial ni
de goulet dtranglement.
En utilisant LDAPBrowser : Nous avons peupl notre annuaire en important un gros fichier ldif
pour pouvoir ensuite faire des tests (avec DirectoryMark) de performance notamment. Limport
de ce fichier ldif gnre un grand nombre de requtes de type ldap_add.
3. Les tests dendurance
Nous avons test notre proxy dans son fonctionnement courant en essayant de dtecter une
augmentation ventuelle des ressources utilises. Les outils utiliss sont lAnalyseur de performance
Windows ainsi que Purify (Rational Corporation).
Linterface LDAP (telle quelle a t conue) et les librairies quelle inclue grent correctement la
mmoire. Toute la mmoire alloue est relche.
Laugmentation des ressources mmoire a t observe lorsque plusieurs threads client sont crs.
Malgr lutilisation de Purify, nous navons pas pu corriger ces problmes de fuites de mmoire.
Nous savons que les threads de la librairie Win32 ne librent pas toutes leurs ressources en fin de
vie.
4. Les tests de robustesse
Ce sont les tests de rsistance du Proxy aux cas dutilisation inhabituels.

Un client peut envoyer des requtes errones. Dans ce cas, le Proxy retourne au client un message
LDAP lui signalant lerreur : erreur de protocole (ResultCode 2).
Le fichier de configuration peut contenir des erreurs. Celles ci peuvent boguer le Proxy
lexcution (variables non initialises, mauvais type de variable). Nous avons dvelopp un
module de vrification du fichier de config : toute variable de configuration non initialise ou
errone est dtecte et signale et le proxy refuse de dmarrer.
5. Les tests de choix de liaison (gestion des referrals)
La raction du proxy aux types de liaisons possibles a t teste :

Comportement gnant :
Si la sortie du proxy est malencontreusement dirige vers son entre, la connexion dun
client, le proxy va lancer autant de threads quil peut (jusqu la limite dfinie dans le fichier
de configuration). Le dernier de ces threads ne pourra pas contacter lannuaire (le proxy
refusera de lancer un nouveau thread) et les diffrents threads lancs se fermeront les uns la
suite des autres. La connexion avec le client sera finalement ferme. Mme comportement au
client suivant. Ce comportement nentrane pas de bug du proxy mais empche les clients
daccder au service (Denial Of Service). Nous ne dtectons pas ce cas dutilisation ni
navertissons loprateur du proxy.

Date: 27/06/00
Page:33/46
Olivier Schmitt
Yannik Soubigou
Comportement dangereux :
Ce cas dutilisation est dangereux si on ne fixe pas de limite au nombre de threads pouvant
tre dmarrs.
Solution :
On pourrait dtecter ce cas dutilisation en effectuant une rsolution DNS des deux couples
(proxy.ipaddress, proxy.port) et (dsa.ipaddress, dsa.port) et en comparant les rsultats. Mais
cette vrification est trop simple si lon envisage le cas de deux proxy qui se dsignent
mutuellement comme tant le serveur dannuaire.
Gestion des referrals :
Politique DROP : fonctionne correctement.
Politique REFERRAL : fonctionne correctement.
Politique CHAINING :
Nous avons test ce mode de fonctionnement et il nous a donn satisfaction.
Cependant, nous navons pas pu entirement le tester. Nos tests se sont limits une
seule url retourne par message LDAP et nous navons pas pu dpasser une
profondeur de 3 en rsolution ( 3 referrals successifs).
Politique MULTICASTING : Non encore dveloppe.
6. Les tests de performance
Nous avons effectu des tests pour valuer les performances de notre proxy, et afin de les comparer
avec les performances de lannuaire seul. Loutil (client LDAP) utilis est DirectoryMark 1.1
(www.mindcraft.com ). Ce BenchMark peut simuler plusieurs clients se connectant et interrogeant
ensemble le Proxy. Nous avons laiss DirectoryMark interroger lannuaire seul et lannuaire en
passant par le proxy pendant 10 minutes environ ( quelques secondes prs).
Nous avons effectu nos tests sur larchitecture rseau dcrite ci-dessous :

Date: 27/06/00
Page:34/46
Olivier Schmitt
Yannik Soubigou
Principe des tests de performance avec DirectoryMark :

DirectoryMark sexcute dans un processus client au sein duquel plusieurs threads peuvent envoyer
des requtes. Chaque thread envoie plusieurs dizaines de fois la mme requte au proxy (ou
directement lannuaire) et ceci pendant au moins X minutes (X est un nombre qui est paramtrable
dans le fichier de config de DirectoryMark).
Au bout de ces X minutes, DirectoryMark sarrte et fourni le bilan de ce qui sest pass et
notamment le nombre de requtes qui ont pu tre envoyes. Le rapport
nombre_de_requtes_traites / X nous donne donc le dbit. DirectoryMark nous donne aussi
dautres informations utiles : dlais de latences, type des transactions...
Tests en rseau local :
Ces tests ont t effectus entre nos deux machines de dveloppement (schmitt et robine)
Rsultats avec un seul thread :
1537 requtes search adresses directement lannuaire
En passant par le proxy : il a pu en traiter 1522 soit une perte de performance de 1%.
53186 requtes search, add, delete et modify adresses directement lannuaire
Rsultats avec 15 threads :
1200 requtes search adresses directement lannuaire,
En passant par le proxy : il a pu en traiter 1192 soit une perte de performance de 0.6%.

Date: 27/06/00
Page:35/46
Olivier Schmitt
Yannik Soubigou
Les oprations effectues pour les tests ci dessus sont souvent des oprations LDAPsearch
lourdes par rapport aux faibles capacits de nos machines : la charge de travail de lannuaire pour
rpondre chaque requte est importante, ce qui explique que seulement 2,4 oprations sont
effectues chaque seconde. Lors de ces tests, nous avons pu constater que la charge CPU du
processus ldapd (l'annuaire) tait de 98% en moyenne et celle du proxy de 1% en moyenne. Cest
pourquoi nous avons effectu dautres tests pour lesquels lannuaire est hberg par un serveur trs
performant.
Tests sur une plate-forme plus performante :
Ces tests ont t effectus entre les machines DGA_SERV et Aladin4. Nous avons effectu 4 fois le
mme test. Le rsultat prsent ci dessous en est la moyenne.
Rsultat avec 5 processus de 10 threads chacun soit 50 clients simultans pendant 10 minutes :
200926 requtes search adresses directement lannuaire
Cette perte de performance peut venir du rseau, des temps de latence dus louverture de socket
ou enfin dune latence due au proxy lui-mme (le plus probable).
Nous avons observ des latences (dlai entre lmission de la requte par le client et la rception
des rsultats par le client) comprises entre 111 ms et 3114 ms.
Les latences constates en sadressant directement lannuaire sont comprises entre 6 ms et 2911
ms.
Nous sommes trs conscients de la difficult dinterprtation de ces tests. En effet, ils dpendent pour
beaucoup de lenvironnement technique utilis :
La machine hbergeant le proxy est-elle puissante, a-t-elle plusieurs processeurs ?
Quelle est la rapidit des connexions rseaux ?
Quutilise t-on comme annuaire ? Est-ce un annuaire LDAP ou un serveur LDAP qui traduise les
requtes en DAP de faon interne ?
Quelle est la performance de la machine qui hberge le serveur dannuaire ?
Quels sont les clients LDAP utiliss ? En quel nombre, et do viennent les connexions du
rseau ?
En raison de toutes ces difficults dinterprtation, on ne prendra les valeurs donnes prcdemment
et notamment les pertes de performance (de 1% dans le cas le plus favorable 30% dans le cas le
plus dfavorable) que de faon indicative. Une campagne de tests planifie et pense de faon
exhaustive et rigoureuse tant ncessaire pour correctement valuer notre logiciel.

Date: 27/06/00
Page:36/46
Olivier Schmitt
Yannik Soubigou
VIII. Amliorations et Bogues

A. Amliorations possibles
Voici des amliorations quil serait sans doute utile dapporter ce proxy :
Localisation des traces :

Actuellement, nos messages de trace sont inscrits en dur dans le code source et ont le format
suivant : nom_classe : :nom_methode description_message
Il serait intressant de dvelopper une macro qui permette de regrouper tous les messages
dans un seul fichier et qui affiche le bon message suivant la langue prfre.
Verrouillage de la console pour accs multiples en criture :

Actuellement, nos traces sont crites sur la console en utilisant des instructions du type cout
<< message << endl ;
Mais tous les threads sont susceptibles de passer de telles commandes en parallle. Les
messages se trouvent donc mlangs lcran, un caractre sur deux par exemple.
On pourrait inclure dans la macro la prise et la libration dun objet mutex qui permettrait
ainsi daccder la console en exclusion mutuelle. Les traces seront ainsi beaucoup plus
lisibles mais cela peut ralentir le proxy si les threads attendent leur tour pour tracer des
informations.
On pourrait aussi inclure dans la macro de trace laffichage pour tous les messages le numro
du thread client qui est concern (variable client_id de lobjet handlerclient). De faon plus
gnrale, rflchir sparer les diffrentes traces des threads client.
Cache de correspondances DN -> @IP pour traitement rapide des referrals

On pourrait mmoriser au sein du proxy une table cache de traduction DN vers adresse IP.
Cette table contiendra au bout dun certain nombre de requtes, pour chaque requte qui a eu
pour consquence la rception dun referral, le DN (Distinguished Name) de lentre
recherche et ladresse de lannuaire rfr qui connat les informations recherches. Cette
table permettra notamment dviter de contacter des annuaires intermdiaires (avec chaque
fois une ouverture de sockets, une requte LDAP et le traitement du rsultat) pour finalement
contacter le bon annuaire.
Implmentation du systme dhabilitations :

Comme nous lavions commenc, nous pourrions implmenter un systme de vrification des
droits des utilisateurs au niveau du proxy en sappuyant pour cela sur les habilitations telles
quelles ont t dfinies dans WebD&CA.
Ajout dun module de statistiques

Ajout dune action excutable par loprateur du proxy qui puisse lui donner des informations
complmentaires sur le fonctionnement du proxy : dlais, dbits, nombre de clients, nombre
moyen de requtes, types des requtes (verbes ldapv3) les plus utiliss, horaires de pointes...

Date: 27/06/00
Page:37/46
Olivier Schmitt
Yannik Soubigou
Permettre laccs plusieurs annuaires

Actuellement, on donne dans le fichier de configuration ladresse (adresse IP et port TCP) de
lannuaire contacter pour rsoudre les requtes des clients. Peut-tre serait-il bon de laisser
la possibilit de contacter plusieurs annuaires pour le cas dannuaires rpliqus et pour
lesquels il faudrait faire de lquilibrage de charge par exemple.
Ne pas dcoder les messages LDAP

Actuellement, chaque message LDAP reu par le proxy est compltement dcod par notre
module LDAP (sappuyant sur le module BER). Les messages sont ensuite traits par
lalgorithme de proxy et r-encods avant dtre envoys au destinataire. Toutes ces tapes
prennent du temps. Il serait peut-tre bon de laisser la possibilit de ne pas dcoder et r
encoder les messages afin dacclrer le fonctionnement du Proxy. Il se contenterait alors de
recevoir sur une socket et de renvoyer exactement le mmes donnes sur une autre socket.
Nanmoins, cette ide ncessite de compltement court-circuiter notre API LDAP et lAPI
Ber de OpenLDAP. En effet, la routine ber_get_next() qui rcupre un message LDAP du
buffer de socket pour le placer sur un buffer sockbuf a des effets de bord sur le message : elle
modifie le dbut du berelement (elle enlve certains tags) et le message ldap nest plus
rcuprable autrement que par un dcodage complet. Ainsi, il faudrait seulement lire sur la
socket le message, le placer dans un buffer temporaire et lenvoyer au destinataire (lautre
socket). Mais de ce fait, il ne serait plus possible de distinguer les messages par leur verbe et
en particulier, il ne serait plus possible de reprer le message bind ni les referrals.
B. Bogues et restrictions
Fuites de mmoires
Nous avons pu observer des fuites de mmoire lors du deboguage du proxy sous Windows
NT. Pour cela, on pourra modifier le proxy pour utiliser les primitives de gestion de thread de
lAPI C comme _beginthread() au lieu des primitives de lAPI Win32 comme CreateThread().
Encodage du champ Controls

Lors des tests du proxy avec un serveur dannuaire GDS dISOCOR, nous avons remarqu
que le codage du champ Controls dune requte LDAP du client ne respecte pas le
protocole LDAPv3 daprs le serveur.
Pour contourner ce bug, que nous navons pas eu le temps de corriger, nous avons
dsactiv lencodage du champ controls dans le proxy.
Ce champ est utilis pour tendre lutilisation des messages LDAP. Dans un cas dutilisation
normale, le fait de dsactiver ces champs na pas dincidence pour le client ou le serveur.

Olivier Schmitt
Yannik Soubigou
IX. Planning
Date: 27/06/00
Page:38/46

Date: 27/06/00
Page:39/46
Olivier Schmitt
Yannik Soubigou
X. Conclusion
Nous tirons globalement de ce stage un bilan trs positif, bien que nous ayons eu faire face des
difficults. Notre capacit les rsoudre et les mthodologies que nous avons employes pour les
rsoudre finalement sont des motifs de satisfaction.
Lvnement tragique de la disparition de notre responsable Marc Fleurisson nous a caus un choc. Il
a fallu par la suite qui nous soyons encore plus autonomes dans notre travail, tout en pouvant compter
sur nos autres collgues.
Nous avons eu un certain nombre de difficults techniques. Notamment la difficult de
comprhension des librairies dOpenLDAP qui sont mal commentes et peu documentes. Nous
avons aussi eu rsoudre des bogues dans notre application et mettre en uvre le dboguage dune
application multithread avec tous les problmes de concurrence daccs et de synchronisation que
cela suppose. Nous navons pas pu trouver de client LDAP qui permette de tester toute la grammaire
LDAP de faon aise.
Mais ce stage a t pour nous le plaisir et loccasion de dcouvrir les technologies dannuaires
LDAP, qui nous taient au dpart compltement inconnues. Il nous a apport la satisfaction de
travailler sur un projet de Recherche et Dveloppement puisque la ralisation de ce logiciel constitue
pour le Dpartement e-Solutions un produit qui pourra sintgrer dans le futur au sein de plusieurs
offres pour les clients de Bull.
Nous avons atteint notre objectif de ralisation dun proxy dannuaire LDAP multi-thread, ne
dpendant pas de librairies commerciales, et qui est capable de rsoudre des referrals. Dautre part, il
est modulaire et les fichiers sources du projet sont entirement accessibles si bien que Bull eSolutions pourra, par des dveloppements ultrieurs, y ajouter les fonctionnalits souhaites par ses
clients.
Ce projet a t loccasion de mettre en pratique la formation thorique que nous avons reue
lENSIMAG, qui sest rvle adapte aux comptences souhaites.

Date: 27/06/00
Page:40/46
Olivier Schmitt
Yannik Soubigou
XI. Bibliographie
Livres :
Implementing LDAP, Wrox press limited 1999
Developper sous windows 95 et NT4.0, Microsoft Press
Internet :
JNDI
Snacc4Java
OSS Nokalva
Michigan University
OpenLDAP
LDAP v2
LDAP v3
Netscape SDK
Serveur de Clayton Donley
Les outils Cup/Jlex
Proxy Innosoft
descript.html
Proxy MaXware
Proxy Nexor Directory Boundary Agent
BullSoft Netwall 4.0
Une documentation X500
DirectoryMark
www.java.sun.com/products/jndi
www.alphaworks.ibm.com/tech/snaccforjava
www.oss.com/news/press060399.html
www.umich.edu/~dirsvcs/
www.openldap.org
www.ietf.org/rfc/rfc1777.txt
www.ietf.org/rfc/rfc2251.txt
developer.netscape.com/software/sdks/index.html
www.linc-dev.com/
http://www.cs.princeton.edu/~appel/modern/java/CUP/
http://www.cs.princeton.edu/~appel/modern/java/JLex/
http://www.innosoft.com/directory_solutions/ilpshttp://www.maxware.no/mias/
http://www.nexor.com/products/dba.htm
http://www.securware.com/netwall/
http://www.spidernet.tm.fr/
www.mindcraft.com

Olivier Schmitt
Yannik Soubigou
XII. Annexes
A. Grammaire ASN1 pour LDAPv3
Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
IMPLICIT TAGS ::=
BEGIN
LDAPMessage ::= SEQUENCE {
messageID
MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest
DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse },
controls
[0] Controls OPTIONAL }
MessageID ::= INTEGER (0 .. maxInt)
maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -LDAPString ::= OCTET STRING
LDAPOID ::= OCTET STRING
LDAPDN ::= LDAPString
RelativeLDAPDN ::= LDAPString
Date: 27/06/00
Page:41/46

Olivier Schmitt
Yannik Soubigou
AttributeType ::= LDAPString

AttributeDescription ::= LDAPString
AttributeDescriptionList ::= SEQUENCE OF AttributeDescription
AttributeValue ::= OCTET STRING
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
AssertionValue ::= OCTET STRING
Attribute ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }
MatchingRuleId ::= LDAPString
LDAPResult ::= SEQUENCE {
resultCode ENUMERATED {
success
(0),
operationsError
(1),
protocolError
(2),
timeLimitExceeded
(3),
sizeLimitExceeded
(4),
compareFalse
(5),
compareTrue
(6),
authMethodNotSupported
(7),
strongAuthRequired
(8),
-- 9 reserved -referral
(10), -- new
adminLimitExceeded
(11), -- new
unavailableCriticalExtension (12), -- new
confidentialityRequired (13), -- new
saslBindInProgress
(14), -- new
noSuchAttribute
(16),
undefinedAttributeType
(17),
inappropriateMatching
(18),
constraintViolation
(19),
attributeOrValueExists
(20),
invalidAttributeSyntax
(21),
-- 22-31 unused -noSuchObject
(32),
Date: 27/06/00
Page:42/46

Olivier Schmitt
Yannik Soubigou
aliasProblem
(33),
invalidDNSyntax
(34),
-- 35 reserved for undefined isLeaf -aliasDereferencingProblem (36),
-- 37-47 unused -inappropriateAuthentication (48),
invalidCredentials
(49),
insufficientAccessRights (50),
busy
(51),
unavailable
(52),
unwillingToPerform
(53),
loopDetect
(54),
-- 55-63 unused -namingViolation
(64),
objectClassViolation
(65),
notAllowedOnNonLeaf
(66),
notAllowedOnRDN
(67),
entryAlreadyExists
(68),
objectClassModsProhibited (69),
-- 70 reserved for CLDAP -affectsMultipleDSAs
(71), -- new
-- 72-79 unused -other
(80) },
-- 81-90 reserved for APIs -matchedDN
LDAPDN,
errorMessage LDAPString,
referral
[3] Referral OPTIONAL }
Referral ::= SEQUENCE OF LDAPURL
LDAPURL ::= LDAPString -- limited to characters permitted in URLs
Controls ::= SEQUENCE OF Control
Control ::= SEQUENCE {
controlType
LDAPOID,
criticality
BOOLEAN DEFAULT FALSE,
controlValue
OCTET STRING OPTIONAL }
BindRequest ::= [APPLICATION 0] SEQUENCE {
version
INTEGER (1 .. 127),
name
LDAPDN,
authentication
AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple
[0] OCTET STRING,
Date: 27/06/00
Page:43/46

Olivier Schmitt
Yannik Soubigou
sasl
-- 1 and 2 reserved
[3] SaslCredentials }
SaslCredentials ::= SEQUENCE {

mechanism
LDAPString,
credentials
OCTET STRING OPTIONAL }
BindResponse ::= [APPLICATION 1] SEQUENCE {
COMPONENTS OF LDAPResult,
serverSaslCreds [7] OCTET STRING OPTIONAL }
UnbindRequest ::= [APPLICATION 2] NULL
SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject
LDAPDN,
scope
ENUMERATED {
baseObject
(0),
singleLevel
(1),
wholeSubtree
(2) },
derefAliases ENUMERATED {
neverDerefAliases
(0),
derefInSearching
(1),
derefFindingBaseObj (2),
derefAlways
(3) },
sizeLimit
INTEGER (0 .. maxInt),
timeLimit
INTEGER (0 .. maxInt),
typesOnly
BOOLEAN,
filter
Filter,
attributes AttributeDescriptionList }
Filter ::= CHOICE {
and
[0] SET OF Filter,
or
[1] SET OF Filter,
not
[2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present
[7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type
AttributeDescription,
-- at least one must be present
substrings SEQUENCE OF CHOICE {
Date: 27/06/00
Page:44/46

Olivier Schmitt
Yannik Soubigou
initial [0] LDAPString,

any [1] LDAPString,
final [2] LDAPString } }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type
[2] AttributeDescription OPTIONAL,
matchValue
[3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
objectName
LDAPDN,
attributes PartialAttributeList }
PartialAttributeList ::= SEQUENCE OF SEQUENCE {
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
SearchResultDone ::= [APPLICATION 5] LDAPResult
ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object
LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation
ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
ModifyResponse ::= [APPLICATION 7] LDAPResult
AddRequest ::= [APPLICATION 8] SEQUENCE {
entry
LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
AddResponse ::= [APPLICATION 9] LDAPResult
Date: 27/06/00
Page:45/46

Olivier Schmitt
Yannik Soubigou
DelRequest ::= [APPLICATION 10] LDAPDN

DelResponse ::= [APPLICATION 11] LDAPResult
ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry
LDAPDN,
newrdn
RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }
ModifyDNResponse ::= [APPLICATION 13] LDAPResult
CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry
LDAPDN,
ava
AttributeValueAssertion }
CompareResponse ::= [APPLICATION 15] LDAPResult
AbandonRequest ::= [APPLICATION 16] MessageID
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName
[0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
response
[11] OCTET STRING OPTIONAL }
END
Date: 27/06/00
Page:46/46

Proxy Ldap

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Proxy Ldap

Uploaded by

Copyright:

Available Formats

Projet de Fin dtudes

Etudiants : Olivier Schmitt et Yannik Soubigou

Projet de Fin dtudes

I. Table des matires

Table des matires _____________________________________________________________2

Contexte de ralisation du projet ________________________________________________7

A. La socit BULL _____________________________________________________________7

V. Etude bibliographique __________________________________________________________9

1. Proxy LDAP ______________________________________________________________12

LAPI JNDI de Sun (Java Naming and Directory Interface)_________________________13

A. Phase prliminaire ___________________________________________________________19

1. Etude de larchitecture globale du logiciel_______________________________________19

1. Structures de donnes _______________________________________________________22

Projet de Fin dtudes

2. Choix darchitecture ________________________________________________________22

VII. Tests et validation ___________________________________________________________31

Les tests de conformit______________________________________________________31

VIII. Amliorations et Bogues _____________________________________________________36

Projet de Fin dtudes

Projet de Fin dtudes

REALISATION D'UN PROXY LDAP

Projet de Fin dtudes

Projet de Fin dtudes

IV. Contexte de ralisation du projet

Projet de Fin dtudes

C. Le service Consulting et Systmes dIntgration

Projet de Fin dtudes

Projet de Fin dtudes

Construction dun Distinguished Name

Projet de Fin dtudes

Les principales modifications apportes par la version 3, apparue en 1997 sont :

Projet de Fin dtudes

E. Proxy LDAP et cahier des charges

Projet de Fin dtudes

F. Les Outils tudis

LAPI JNDI de Sun (Java Naming and Directory Interface)

Projet de Fin dtudes

Projet de Fin dtudes

Projet de Fin dtudes

Innosoft LDAP Proxy Server :

Projet de Fin dtudes

Projet de Fin dtudes

Netscape Browser et Netscape AddressBook

Projet de Fin dtudes

Projet de Fin dtudes

Projet de Fin dtudes

Projet de Fin dtudes

B. Dveloppement dune interface LDAP

Les mthodes de classes

Projet de Fin dtudes

Une mthode print pour laffichage des messages LDAP.

Schma de fonctionnement de linterface LDAP

Projet de Fin dtudes

C. Architecture globale du proxy

Projet de Fin dtudes

Cration des structures de donnes globales et partages

Projet de Fin dtudes

Nous avons prouv la ncessit de conserver en mmoire un certain nombre dinformations

D. Algorithme de traitement des messages

Projet de Fin dtudes

Projet de Fin dtudes

DROP : le referral nest pas

REFERRAL : le referral est

CHAINING : le proxy suit le