Vous êtes sur la page 1sur 46
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 1
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 1
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 1

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:1/46

Rapport de projet de fin d’études ENSIMAG

Page: 1 / 46 Rapport de projet de fin d’études ENSIMAG Conception et Réalisation d’un proxy

Conception et Réalisation d’un proxy d’annuaire LDAP

Etudiants : Olivier Schmitt et Yannik Soubigou Tuteur Ensimag : Brigitte Plateau Encadrement Bull : Marc Fleurisson Durée : du 1er janvier au 30 juin 2000 Lieu : Bull SA 1, rue de Provence 38432 Echirolles

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 2
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 2
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 2

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:2/46

I. Table des matières

I. Table des matières

2

II. Remerciements

4

III. Introduction

5

A. Généralités

5

B. Contexte

5

 

C. Sujet

5

IV.

Contexte de réalisation du projet

7

A. La société BULL

7

B. Bull France

7

C. Le service Consulting et Systèmes d’Intégration

8

V.

Etude bibliographique

9

A. LDAP et les annuaires

9

B. Le protocole LDAP

10

C. L’encodage 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 étudiés

13

 

1. L’API JNDI de Sun (Java Naming and Directory Interface)

13

2. Netscape Directory SDK 4.0 for Java

14

3. Netscape Directory SDK 4.0 for C

14

4. L’outil Snacc4Java d’IBM

14

5. Le couple Cup/Jlex

15

6. Les outils d’OSS Nokalva

15

7. Les outils fournis par les chercheurs de l’université du Michigan

15

8. Les outils fournis par le groupe OpenLDAP

16

9. Les proxy LDAP disponibles sur le marché

16

10. Les clients LDAP disponibles

17

VI.

Développement

19

A. Phase préliminaire

19

1. Etude de l’architecture globale du logiciel

19

2. Etude des librairies fournies par OpenLDAP

21

B. Développement d’une interface LDAP

22

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 3
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 3
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 3

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:3/46

2. Choix

d’architecture

22

3. Choix de conception

22

C. Architecture globale du proxy

24

D. Algorithme de traitement des messages

26

E. Gestion de la résolution des referrals

27

VII. Tests et validation

A. Tests et validation

31

31

1. Les tests de conformité

31

2. Les tests de stress

31

3. Les tests d’endurance

32

4. Les tests de robustesse

32

5. Les tests de choix de liaison (gestion des referrals)

32

6. Les tests de performance

33

VIII.

Améliorations et Bogues

36

A. Améliorations 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

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 4
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 4
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 4

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:4/46

II. Remerciements

Nous voudrions remercier toutes les personnes qui par leur aide ou simplement par leur gentillesse ont contribuées d’une façon ou d’une autre à la bonne réalisation du projet dont nous avons eu la charge. Nous tenons donc à remercier tous les membres de l’équipe e-Solutions du site d’Echirolles pour leur disponibilité et leur sympathie. Nous tenons tout particulièrement à remercier Antoine Geronimi, Thierry Dessenne, Jérôme Camilleri et Vladimir Plotto pour leur disponibilité, l’aide qu’ils nous ont apportée et leur expérience. Nous remercions également Emmanuel Chabani, Pascal Deveze, Carole Hébrard et Serge Reboul. Enfin, nous tenons à témoigner de toute notre sympathie pour les proches de notre maître de stage Marc Fleurisson et de la douleur que son décès a provoquée en nous. Nous avions noué avec lui des relations amicales qui dépassaient le cadre strictement professionnel. Il restera dans notre mémoire.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 5
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 5
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 5

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:5/46

A. Généralités

III.

Introduction

Le présent document est le rapport du projet de fin d’études de Yannik SOUBIGOU et Olivier SCHMITT, élèves ingénieurs à l’ENSIMAG. Il a comme but de situer le contexte du projet, de décrire son sujet, les méthodes et outils utilisés ainsi que les résultats obtenus.

B. Contexte

Ce projet s’est déroulé à BULL Echirolles dans le service Consulting & Systèmes d’Intégration. Il a été commencé à mi-temps, de début janvier au 31 mars. Cette première période a été principalement passée en études bibliographiques. Elle a été suivie de quatre mois à plein temps. L’encadrement était initialement assuré par Marc Fleurisson. Suite à son décès, Antoine Géronimi et Thierry Dessenne se sont partagés le rôle de chef de projet.

C. Sujet

Les annuaires (norme ISO X500) permettent de gérer de façon centralisée les données de l’entreprise concernant les personnes, leurs habilitations, la configuration des logiciels, des données liées à

Le protocole d’accès et de requêtes à 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 accès par des clients légers, qui est beaucoup plus simple à implémenter et à utiliser. DAP est toujours utilisé et supporté par des annuaires DAP comme celui d’ISOCOR et LDAP constitue le protocole d’accès par Internet. La version 2 de ce protocole (RFC 1777) est très largement supportée et la version 3 (RFC 2251) tend aujourd’hui à devenir le standard d’accès aux annuaires.

l’architecture du réseau, les machines

Le sujet initial du stage était : « Développement d’un Proxy LDAP». Il s’agissait de développer une application qui, placée 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 amenés à jouer un rôle clé, en particulier le contrôle d'accès aux informations contenues dans l'annuaire.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 6
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 6
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 6

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:6/46

OBJECTIFS :

Fonctionnalités demandées : Le proxy LDAP proposera les fonctions de :

Gestion du contrôle d'accès aux informations contenues dans les annuaires. Distribution et agrégation des requêtes LDAP sur les serveurs d'annuaire. Cache des requêtes. Technologies mises en œuvre : cette application sera réalisée en Java (Application, Servlet, Applet), mettra en œuvre les protocoles et schémas d'Annuaire LDAP (interface JNDI), et sera sécurisée par SSL.

PROFIL/COMPETENCES :

Compétences requises : Java, HTML, Unix. Compétences souhaitées : LDAP, NT.

Durée 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

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 7
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 7
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 7

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:7/46

IV. Contexte de réalisation du projet

A. La société BULL

Le groupe BULL est

l’une

sociétés d'informatique en Europe. Evoluant depuis le

dépôt de brevet en Norvège sur des machines à cartes perforées par Fredrik Rosen.

Bull

informatique international

basé en Europe qui emploie

18 358 personnes dans plus

de 100 pays.

réalisé un chiffre d'affaires de 3,8 milliards d’euros dont plus de 65% hors de France, son pays d’origine.

a

des

plus

importantes

est

un

groupe

En 1999,

il

a des plus importantes est un groupe En 1999 , il Bull fournit des solutions sécurisées

Bull fournit des solutions sécurisées pour le commerce électronique et Internet portant principalement sur trois domaines :

les solutions d’intégration,

les solutions d’infrastructure garantissant haute disponibilité et sécurité,

les solutions d’info gérance et de services de support.

B. Bull France

Bull France réalise le tiers du chiffre d’affaire du groupe et emploie plus de 6000 personnes. C’est un intégrateur de technologies qui fournit des solutions adaptées aux besoins de chaque client, en utilisant l’offre de produits et de services de BULL, associée à l’offre et aux compétences des meilleurs partenaires. Le Groupe Bull a adopté une stratégie d’indépendance vis-à-vis du gouvernement et a conclu des alliances dans le monde entier.

Après un développement aussi rapide, une restructuration a débuté en 1994 qui a impliqué la fermeture de plusieurs usines de fabrication dont l’activité avait été réduite. L’activité de Bull s’est progressivement concentrée sur les tâches d’intégration. Les mesures prises afin de réduire les coûts avaient pour but de permettre à la compagnie de retourner dans le secteur privé, ce qui se fait depuis 1994, avec comme principaux actionnaires de départ France Télécom, NEC et Motorola.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 8
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 8
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 8

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:8/46

C. Le service Consulting et Systèmes d’Intégration

Le service CSI emploie 4000 personnes dans 374 agences dans le monde et recrute 1100 experts par

an. CSI France réalise un chiffre d’affaire de 2 milliards de francs et fournit des services dans les différents pôles de compétence suivants :

E-Solutions

Administration et Sécurité

Architecture et Information

Formation

Applications Consulting

Le service CSI ( Consulting et Intégration de Systèmes ) est très récent. Il a été créé dans le but de construire des systèmes d’informations qui répondent le mieux possible aux attentes des clients. Leur

but étant d’utiliser un capital d'expérience et d'expertises afin d’aboutir à une offre personnalisée couvrant les domaines décisifs du système d’information. Ce service bénéficie d’une implantation régionale et européenne au plus près des clients. En effet, le service CSI est représenté dans les villes

et

françaises indiquées sur la carte suivante, avec deux centres d’expertise européens : Paris Grenoble.

Metz Caen Paris k Rennes Tours Nantes Poitiers Lyon k Grenoble Bordeaux Toulouse Montpellier Marseille
Metz
Caen
Paris
k
Rennes
Tours
Nantes
Poitiers
Lyon
k
Grenoble
Bordeaux
Toulouse Montpellier
Marseille
Nice

Lille

Nancy Strasbourg

Le service CSI pourra ainsi conseiller le client afin d’anticiper les choix d’évolution, conduire et déployer les projets d'envergure et fournir des expertises multiples dans la durée.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 9
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 9
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 9

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:9/46

V.Etude bibliographique

Pendant la partie mi-temps du stage, de début janvier à fin février, nous avons recherché les meilleurs outils et cherché à faire les meilleurs choix d’implémentation 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 systèmes ouverts — Annuaire) permettent de gérer de façon centralisée les données de l’entreprise concernant les personnes, leurs habilitations,

La

définition de cette norme d’annuaires a été élaborée à 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 d’accès et de requêtes à ces annuaires a été nommé DAP (Directory Access Protocole) et utilisait l’architecture à couches d’ISO. Ce protocole a été abandonné et remplacé par le protocole LDAP (Lightweight Directory Access Protocole) pour les accès par des clients Internet, LDAP fonctionnant au-dessus de IP et de TCP et étant beaucoup plus simple à implémenter et à utiliser sur Internet. La version 2 de ce protocole (RFC 1777 parue en 1995) est très largement supportée et la version 3 (RFC 2251 parue en 1997) tend aujourd’hui à devenir le standard d’accès aux annuaires sur Internet.

la configuration des logiciels, des données liées à l’architecture du réseau, les machines

Les annuaires X.500

Modèle de données Un annuaire X500 est une collection d'informations de toutes catégories. Ces informations sont stockées dans la "Directory Information Base" ou DIB. La DIB est composée d'entrées. Ces entrées sont constituées de un ou plusieurs attributs qui peuvent prendre une ou plusieurs valeurs.

Structure Les entrées de la DIB sont organisées hiérarchiquement, sous forme d'un arbre, le DIT ou Directory Information Tree. Ce DIT contient donc deux types d’entrées :

Les nœuds qui sont des entrées à part entière, et sont la base d'un sous-arbre du DIT.

Les feuilles qui terminent les branches des sous-arbres.

Chaque entrée de l’arbre est nommée par un nom tenant compte du chemin parcouru dans l'arbre pour l'atteindre, depuis la racine. Il existe deux appellations pour ces entrées :

Le nom distinctif relatif (RDN ou Relative Distinguished Name).

Le nom distinctif (dn ou Distinguished Name ), concatenation des différents RDNs du chemin utilisé depuis la racine, pour joindre l’entrée concernée.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 10
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 10
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 10

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:10/46

Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 10 / 46 Construction d’un Distinguished Name B. Le

Construction d’un Distinguished Name

B. Le protocole LDAP

LDAP (Lightweight Directory Access Protocol) est le protocole d’accès aux annuaires LDAP. Il permet de passer des requêtes à un serveur d’annuaire et de retourner les résultats aux clients. Ce protocole fonctionne au-dessus de la couche TCP et le port d’écoute standard des serveurs LDAP est le port 389.

La version 2 parue en 1995 définissait les types de messages (verbes ) suivants :

SearchRequest et SearchResponse : pour chercher des entrées suivant un filtre.

ModifyRequest et ModifyResponse : pour modifier les attributs d’une entrée.

AddRequest et AddResponse : pour ajouter une entrée.

DelRequest et DelResponse : pour effacer une entrée.

ModifyDNRequest et ModifyDNResponse : pour modifier le DN d’une entrée. CompareRequest et CompareResponse : pour comparer des valeurs d’attributs avec des valeurs données.

BindRequest et BindResponse : pour débuter une connexion LDAP.

AbandonRequest : pour demander au serveur d’abandonner la requête en cours.

UnbindRequest : pour finir une connexion LDAP.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 11
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 11
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 11

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:11/46

Les principales modifications apportées par la version 3, apparue en 1997 sont :

Support complet de LDAPv2.

Apparition d’un mécanisme de referral (cf. la partie V.C. Les referrals de LDAPv3).

Possibilité d’utiliser les mécanismes SASL (Secured Authentification Socket Layer).

Le protocole peut être étendu pour de nouvelles opérations.

Les nouveaux verbes apportés par la version 3 sont :

SearchResultEntry, SearchResultDone et SearchResultReferral : complètent SearchResponse.

ExtendedRequest et ExtendedResponse.

Les messages peuvent aussi être étendus par un champ «controls » situé en fin de message et qui peut être interprété par le serveur d’annuaire pour que celui-ci adopte un comportement spécifique.

Nous nous sommes familiarisés avec ces notions en lisant les RFC 1777 (LDAPv2) et 2251 (LDAPv3) et en manipulant l’annuaire Netscape Directory Server 4.1

C. L’encodage BER de la grammaire ASN1 de LDAP

La grammaire telle que décrite dans l’annexe A spécifie le protocole LDAPv3 suivant les règles ASN1 (Abstract Syntax Notation 1). Les messages LDAP sont alors codés pour transmission sur le réseau suivant les règles d’encodage BER (Basic Encoding Rules). Les différents éléments de la grammaire ASN1 prennent des valeurs hexadécimales précises et les chaînes de caractères comme les entiers sont codés tels quels. Un module de décodage d’élément BER est donc nécessaire à la récupération de messages LDAP.

D. Les referrals de LDAPv3

L’information que contient un annuaire est parfois partagée entre plusieurs DIT. Dans ce cas, une information est ajoutée sur l’arbre indiquant que le sous arbre en question se trouve sur un autre DIT. L’adresse du nouveau DIT et l’endroit de l’arbre où l’on peut trouver cette information sont codées sous forme d’URL. Un exemple d’URL LDAP :

ldap://aladin4.frec.bull.fr:1389/ou=bull,o=unedic.fr??base?

Elle signifie qu’il faut s’adresser au serveur se trouvant sur la machine aladin4.frec.bull.fr et écoutant sur le port 1389. Le Distinguished Name de cette entrée est «ou=bull, o=unedic.fr ».

LDAPv3 permet au serveur de transmettre cette information aux clients. Ce mécanisme est appelé referral. Quand un client LDAPv3 émet une requête concernant une information qui ne se trouve pas

dans l’annuaire concerné, il se voit retourner un avis de referral vers un second annuaire (annuaire

délégué ).

l’annuaire délégué.

Il sait alors qu’il peut trouver l’information qu’il veut en expédiant la même requête à

Ce mécanisme permet de sous-traiter (déléguer) des branches de l’arborescence de l’annuaire à un autre serveur d’annuaire distant.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 12
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 12
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 12

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:12/46

E. Proxy LDAP et cahier des charges

1. Proxy LDAP

Le but principal d’un Proxy est d’ajouter des fonctionnalités à la relation client/serveur sans avoir à toucher au serveur souvent déjà lourd ni aux clients qui sont trop nombreux pour en envisager une modification.

Quelques exemples de fonctionnalités :

La gestion de cache :

Le proxy intercepte les requêtes du client et garde en mémoire les résultats associés aux dernières requêtes traitées. S’il reçoit une requête qu’il a encore en mémoire, il retourne directement le résultat au client sans s’adresser au serveur. Le routage :

Le proxy peut adresser les requêtes du client à un serveur parmi plusieurs après analyse de la requête. Le Proxy constitue, pour les clients, un unique point d’entrée à un service. Le filtrage :

Le Proxy peut refuser de transmettre au serveur des requêtes de clients non autorisés ou des types de requêtes interdits. Il peut aussi filtrer les résultats retournés par le serveur.

Un Proxy LDAP est donc une application placée entre le client et le serveur qui analysera les messages LDAP transitant entre eux. Il pourra agir sur ces messages suivant les fonctionnalités qui lui sont données.

2. Cahier des charges

Fonctionnalités de bases :

Le Proxy doit posséder toutes les fonctionnalités de base que doit posséder un Proxy. C’était le but de notre première partie de stage : développer un Proxy qui transmette d’un sens comme de l’autre les messages LDAP après en avoir décodé et analysé les informations. Nous devions développer une application performante, modulaire et pouvant servir plusieurs clients sans perte majeure de performance. Temps de traitement des requêtes :

Le temps de traitement des requêtes par le Proxy ne doit pas être trop important. Dans toutes les utilisations futures et possibles du logiciel, une attention particulière sera portée à la rapidité de traitement des requêtes des clients. Résistance à une charge élevée :

Tout Proxy doit être prêt à subir une demande de connexions très importante. Celui-ci ne doit donc pas montrer de perte de performance trop importante s’il doit traiter un nombre important de connexions clientes. Les contraintes de prix étaient importantes aussi. Nous devions réaliser notre proxy en n’engageant que très peu de frais.

Fonctionnalités supplémentaires :

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 13
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 13
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 13

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:13/46

Jusqu’au mois d’avril, la principale fonctionnalité que devait présenter le Proxy portait sur la sécurité. La gestion des droits des clients sur les entrées de l’annuaire est souvent faite par le serveur lui- même. Cependant, ce type de gestion propriétaire a ses limitations. Nous devions donc ajouter au Proxy un module qui identifierait les clients et leur affecterait des droits suivant une base de données stockée dans un annuaire. Le Proxy transmettrait alors uniquement les messages d’un client après vérification de ses droits.

A la fin du mois d’avril, suite au décès de Marc Fleurisson, nous avons parlé du futur de notre stage

avec Jérôme Camilleri, Antoine Geronimi et Thierry Dessenne. L’ajout de cette fonctionnalité a alors du être abandonnée au profit d’une gestion des referrals au niveau du Proxy. En effet, personne ne pouvait plus nous aider sur cette partie et l’ajout de la gestion des referrals intéressait directement Antoine Geronimi et Thierry Dessenne dans le cadre de leur projet. Beaucoup de client LDAPv2, ne comprenant pas les referrals, sont encore utilisés aujourd’hui. La fonctionnalité que nous devions ajouter au Proxy permettrait de rendre la présence de referrals invisible pour les clients. Quand celui-ci reçoit un avis de referral, il doit traduire l’URL qui lui est transmise, ouvrir une connexion vers l’annuaire délégué, lui transmettre la requête et transmettre la ou les réponses au client après avoir fermé la connexion avec le deuxième annuaire. Le tout doit être caché au client.

F. Les Outils étudiés

1. L’API JNDI de Sun (Java Naming and Directory Interface)

Au début du stage, et en accord avec notre sujet initial, nous avons axé notre recherche sur des outils Java, et plus particulièrement JNDI(java Naming and Directory Interface). En effet, Marc Fleurisson nous avait orienté vers JNDI parce que cette interface était utilisée avec succès dans le projet WebD&CA pour interroger un annuaire LDAP. La technologie Java nous a aussi semblé intéressante car un proxy est un logiciel qui doit communiquer sur le réseau et que Java est bien adapté pour cette tâche. De plus, profiter de fonctionnalités comme le «garbage collector » nous paraissait intéressant. Néanmoins, le problème des performances risquait de se poser, surtout pour un proxy, qui par essence doit répondre rapidement.

Cette API est de très haut niveau et permet donc de développer rapidement des clients LDAP. Elle fonctionne de façon modulaire. Le module JNDI en lui-même n’offre que peu de fonctionnalités mais

il permet de fédérer sous une interface unique toutes les interfaces qui offrent des services de

nommage ou d’annuaire. En effet, un module LDAP, DNS ou encore NIS (ces modules sont appelés Service Provider) peuvent se brancher dans le module JNDI pour offrir des services spécifiques pour les protocoles respectifs. Pour plus de détails, on se reportera à l’url suivante :

http://www.java.sun.com/products/jndi/

Pour nous familiariser avec cette API nous avons développé un petit client java qui se connecte à un annuaire en s’authentifiant grâce à un nom et un mot de passe et qui passe une requête de type

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 14
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 14
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 14

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:14/46

« LdapSearch » selon un filtre sur les attributs d’une (ou des) entrée(s) de l’annuaire. Ce client traite ensuite les résultats retournés et les présente à l’utilisateur.

Ce programme nous a permis de nous rendre compte que l’API JNDI et son Service Provider LDAP ne permettent que de faire des requêtes et de traiter les résultats. C’est seulement une API cliente qui, comme JDBC, passe des requêtes à un serveur et traite les résultats. Nous ne pouvions donc pas utiliser cette interface pour notre proxy car celui-ci doit pouvoir jouer le rôle de serveur : il doit savoir interpréter une requête qui arrive et générer des résultats. Nous avons donc ensuite cherché d’autres API en Java qui offrent des fonctionnalités serveur.

2. Netscape Directory SDK 4.0 for Java

Cette API éditée par Netcape fourni des primitives Java pour adresser des requêtes à un annuaire LDAP et traiter les résultats. Elle offre globalement les mêmes fonctionnalités que le JNDI ( client uniquement ) et son Service Provider LDAP, en plus d’être spécialement optimisée pour s’interfacer avec l’annuaire LDAP de la même société : le Netscape Directory Server 4.1 Pour plus de détails 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 éditée par Netcape fourni des primitives C pour adresser des requêtes à un annuaire LDAP et traiter les résultats. Elle offre globalement les mêmes fonctionnalités que l’API précédente (client uniquement) et est spécialement optimisée pour s’interfacer avec l’annuaire LDAP de Netscape. Pour plus de détails on se reportera à :

http://developer.netscape.com/software/sdks/index.html?content=/tech/directory/downloads.html

4. L’outil Snacc4Java d’IBM

L’outil Snacc4Java (Snacc for Java) est édité par le département Alphaworks d’IBM qui effectue différents travaux exploratoires dans différents domaines de la technologie. Ce produit effectue très bien la tâche pour laquelle il a été conçu mais il ne constitue pas encore un produit commercial. Il faut plus le voir comme un démonstrateur de technologie. Snacc est un générateur d’analyseur de grammaire ASN1 en Java. Il suffit de lui fournir en entrée la grammaire ASN1 de LDAPv3 dans notre cas pour qu’il produise un ensemble de classes Java qui analysent et décodent cette grammaire. Cet outil offre des services beaucoup plus puissants que le JNDI puisque c’est un outil client et serveur : il permet d’envoyer des requêtes et de traiter les résultats mais aussi de recevoir des requêtes et d’envoyer des résultats. Ce produit fourni un support complet de la grammaire LDAP. Un petit serveur LDAP a même été développé par Clayton Donley en utilisant cette interface. Pour plus de détails sur son travail, on se reportera à : http://www.linc-dev.com/ Cet outil s’est révélé être un bon candidat pour notre proxy et c’est donc pourquoi nous avons réalisé une maquette (une toute première version simplifiée) de notre proxy en utilisant cette interface, qui a

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 15
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 15
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 15

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:15/46

bien rempli son rôle. Néanmoins, nous n’avons pas continué dans cette voie pour des raisons de performance et de non-disponibilité commerciale officielle de cette API. Pour plus de détails, 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 décoder les messages émis par un client, nous avons envisagé un moment de trouver des outils d’analyse grammaticale analogues aux célèbres Yacc et Lex. Comme nous étions dans notre optique de développement en Java, nous avons trouvé les outils Cup et Jlex qui sont respectivement un générateur de reconnaisseur de grammaire et un analyseur lexical. Ces deux outils auraient pu nous permettre, moyennant une réécriture de la grammaire LDAP au format reconnu par ces outils, de générer un ensemble de classes reconnaissant cette grammaire. Mais il nous aurait quand même manqué un moteur d’encodage et de décodage ASN1. Nous n’avons donc pas poussé plus loin cette recherche. Pour plus de détails, on se reportera aux références suivantes :

http://www.cs.princeton.edu/~appel/modern/java/CUP/

http://www.cs.princeton.edu/~appel/modern/java/JLex/

6. Les outils d’OSS Nokalva

La compagnie américaine OSS Nokalva, réputée 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é. L’un des objectifs de notre stage était de produire un proxy qui n’implique que peu de frais. Nous avons donc renoncé à utiliser ces outils. Pour plus de détails, on se reportera à :

http://www.oss.com/products/products.html

7. Les outils fournis par les chercheurs de l’université du Michigan

Les chercheurs et étudiants de l’université du Michigan ont été pour une bonne partie à l’origine des travaux qui ont conduit aux normes d’annuaires LDAP actuelles. Leurs travaux font référence dans le monde entier et ils continuent aujourd’hui de développer des logiciels utilisant LDAP et les annuaires

X500.

L’intérêt principal de ces logiciels est qu’ils sont gratuits et pour la plus grande partie le code source de ces logiciels est librement accessible. Aujourd’hui, ils continuent de développer des logiciels client LDAP et des serveurs mais cette activité semble devoir s’arrêter bientôt. Elle n’est plus aussi importante qu’il y a quelques années. Ces travaux ont été repris par la communauté de développeurs OpenLDAP qui eux, travaillent à améliorer des produits gratuits et dont le code source est accessible librement. Pour plus de détails, on se reportera à : http://www.umich.edu/~dirsvcs/

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 16
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 16
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 16

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:16/46

8. Les outils fournis par le groupe OpenLDAP

OpenLDAP est une communauté de développeurs issus du monde entier et qui travaillent ensemble pour développer une suite d’applications (clientes et serveurs) et d’outils de développement liés à 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 l’Université du Michigan. Ces outils, clients et serveurs sont programmés 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 février 2000 pour programmer notre proxy. La version 1.2.10 de ce package est actuellement (en juin 2000) la dernière version disponible. Nous avons utilisé la librairie de codage et de décodage BER (ASN1 Basic Encoding Rules) de ce package et nous l’avons complètement détachée (en prenant juste les fichiers nécessaires à une bonne compilation) du package pour l’incorporer dans notre proxy. Cette approche a des avantages, dont l’espoir de performances (programmation en langage C), la gratuité et la disponibilité des fichiers source du produit. Mais elle a aussi des inconvénients dont le fait que les fichiers source soient très peu commentés et assez complexes et aussi le fait que nous ne soyons pas certains que le codage et décodage BER soit complet et débogué. Pour plus de détails, on se reportera à : http://www.openldap.org

9. Les proxy LDAP disponibles sur le marché

Innosoft LDAP Proxy Server :

Ce proxy est à ce jour l’un des proxy LDAP commerciaux les plus réputés. Il offre les fonctionnalités complémentaires suivantes : équilibrage de charge entre serveurs répliqués, configuration fine du filtrage, filtrage des domaines et des adresses IP, filtrage des verbes, réécriture des résultats, et prévention des attaques de type «déni de service » et «téléchargement complet de l’annuaire ». http://www.innosoft.com/directory_solutions/ilps-descript.html

MaXware LDAP Access Engine Ce proxy appelé fait partie de l’architecture Enterprise Meta Solution (EMS) et offre les fonctionnalités complémentaires suivantes : gestion de plusieurs jeux de caractères, contrôle d’accès et filtrage des attributs, limitation en temps ou en taille du résultat des requêtes, support de LDAP v2 et v3, résolution 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 l’autre qui traite les requêtes et effectue des vérifications au niveau du protocole LDAP. Ce proxy est configurable : un module de contrôle d’accès permet de spécifier qui peut accéder à quelles données, il permet aussi de cacher des branches de l’annuaire, et un filtrage fin des données est possible. Ce proxy, dans le but de pouvoir fonctionner sur un FireWall a été testé par un centre d’évaluation et a obtenu la certification ITSEC E3. http://www.nexor.com/products/dba.htm

BullSoft Netwall 4.0 LDAP Proxy

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 17
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 17
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 17

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:17/46

Un proxy LDAP a été développé au sein de BullSoft en 1999. Ce proxy codé en langage C utilise un moteur de codage et de décodage fourni par OSS et s’inspire de l’architecture du proxy DNS de Netwall 4.0 : le démon inetd instancie un processus pour chaque demande de connexion de clients. Ce proxy offre comme fonctionnalité complémentaire la confirmation de l’identité du client en effectuant une résolution DNS simple et inversée du nom du client. Ce proxy ne fait pas actuellement partie de l’offre commerciale BullSoft de Netwall. http://www.securware.com/netwall/

10. Les clients LDAP disponibles

Le Navigateur LDAPBrowzer LDAPBrowzer est un client LDAP gratuit développé en Java. Il permet la consultation, la modification d’un annuaire LDAP et l’importation d’entrées dans l’annuaire a partir de fichiers ldif. C’est le client que nous avons utilisé le plus souvent pour nos tests. Nous avons découvert un Bug : il ne permet pas d’ajouter manuellement des entrées. http://www.iit.edu/~gawojar/ldap/

des entrées. http://www.iit.edu/~gawojar/ldap/ Visual LDAP C’est un client que nous avons récupéré en

Visual LDAP C’est un client que nous avons récupéré en version de démonstration. Toutes les fonctionnalités n’étaient donc pas présentes et il était moins simple d’utilisation que le précédent. http://www.CQSL.com

Directory Mark Ce client, contrairement aux autres n’est pas graphique. Il nous a particulièrement servi à tester les performances de notre Proxy. En tant que BenchMark d’annuaire, il donne des informations intéressantes sur les performances d’un serveur d’annuaire. Il prend en entrée un script qui lui permet de générer des requêtes qu’il transmet alors au serveur. Sa fonctionnalité la plus intéressante est sa possibilité de simuler plusieurs clients qui se connectent simultanément au serveur. www.mindcraft.com

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 18
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 18
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 18

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:18/46

Netscape Browser et Netscape AddressBook Ce sont deux outils fournis avec Netscape Communicator. Le Navigateur Netscape permet d’envoyer des requêtes LDAPSearch que l’utilisateur entre sous forme d’URL. Il nous a principalement servi à tester les filtres de recherche LDAP. Le Carnet d’Adresses Netscape permet la recherche d’informations dans un annuaire LDAP. Son mode de fonctionnement différent nous a permis de tester plus profondément notre Proxy.

Netscape Directory Console C’est la console d’administration du serveur d’annuaire Netscape Directory Server. Elle permet la consultation, la modification et l’administration d’un annuaire. Nous l’avons utilisé pour peupler et administrer notre serveur de tests.

Les commandes DOS fournies avec l’annuaire Netscape Elle permettent d’envoyer à l’aide de commandes DOS, des requêtes LDAP de consultation et de modification. On trouve les commandes suivantes : ldapdelete, ldapsearch, ldapmodify et ldapcmp.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 19
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 19
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 19

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:19/46

VI.

A. Phase préliminaire

Développement

Une fois que nous nous étions fixés sur les outils à utiliser, en l’occurrence les outils fournis par OpenLDAP, nous avons mené une étude préliminaire permettant de concevoir notre proxy.

1. Etude de l’architecture globale du logiciel

Il nous a été présenté un proxy ayant déjà été développé par BullSoft, s’intégrant dans le produit NetWall. Ce proxy a été développé en C pour Unix (Aix) en utilisant un moteur de codage et de décodage des messages LDAP fourni par OSS. Ce proxy ne convenait donc pas à ce que l’on souhaitait faire puisque la licence du module fourni par OSS est très onéreuse. De plus, ce proxy n’avait pas été développé de façon multithreadée : un processus instance du proxy devant être démarré à chaque connexion d’un client par le démon «inetd ». L’instanciation d’un processus étant beaucoup plus longue que celle d’un thread au sein d’un processus, il nous a semblé qu’il serait préférable de développer le nôtre de façon multithread. Nous avons de plus pensé à développer notre proxy en langage C++ dans un soucis de clarté et de facilité de développement : nous pensons ici à toutes les fonctionnalités supplémentaires que le C++ apporte au C comme la surcharge d’opérateurs, de constructeurs, de méthodes, l’allocation dynamique et la gestion des flux. Il nous a été fourni par Marc Fleurisson comme plate-forme de développement 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 différentes API celles que nous allions utiliser et à nous former à utiliser celles-ci pour réaliser une première version (une maquette) du proxy. La principale motivation qui nous a guidée pour ces choix fut l’objectif 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 réseau. Le protocole LDAP étant conçu pour fonctionner au-dessus de IP et de TCP, il nous fallait choisir parmi les différentes librairies offrant le mécanisme de Socket. La librairie C standard de gestion des communications par socket sous Windows est appelée winsock. Elle comporte des mécanismes et des primitives socket très similaires à ce que l’on trouve sous Unix et elle apporte aussi des fonctionnalités supplémentaires telles que la détection d’évènements réseau comme la fermeture distante de la connexion. La librairie MFC (ou plutôt architecture orientée objet de Microsoft) défini aussi des classes permettant la gestion de sockets. Ces classes apportent des fonctionnalités supplémentaires et permettent de manipuler de façon «objet » les sockets. Notre objectif de portabilité maximale nous a amené à utiliser les mécanismes socket standards de winsock, qui seront facilement portable.

Un autre de ces choix était relatif à la gestion du caractère multithread de notre proxy. Trois librairies permettent de gérer des threads sous Windows. On trouve la librairie C standard, la l’API Win32 et l’architecture à objets MFC. Nous n’avons pas utilisé les classes de la librairie MFC car la gestion de threads aurait été de cette façon trop différente de ce qui se fait sous Unix. La librairie standard C et l’API Win32 offrent presque le même niveau de fonctionnalités et ressemblent fortement à ce que l’on peut trouver sous Unix. Nous avons utilisé l’API Win32 pour notre proxy. Il ne s’est pas agit là

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 20
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 20
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 20

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:20/46

d’un vrai choix car nous n’avons découvert l’existence des primitives multithread de la librairie C qu’à la fin de notre projet.

Le proxy avait été initialement prévu pour apporter les valeurs ajoutées suivantes :

Gestion d’un système d’habilitations pour pouvoir s’interfacer avec WebD&CA (un logiciel de

Simple proxy permettant de cacher l’architecture physique des annuaires

consultation d’annuaire LDAP et de délégation d’administration développé par BULL ) et identifier les clients qui se connectent et leur affecter des droits d’accès Routage : Gestion des referrals pour pouvoir résoudre les références à des données d’annuaires réparties même si le client ne sait pas résoudre les referrals. Cache : gestion d’une mémoire cache au sein du proxy pour accélérer l’accès aux données par les clients.

Cache : gestion d’une mémoire cache au sein du proxy pour accélérer l’accès aux données par

La fonctionnalité principale qui avait été prévue était la gestion des habilitations. Suite à une réorientation de nos objectifs en cours de stage, il a été décidé d’abandonner cette partie, en raison de la complexité de la tâche et du temps qui nous restait. Il a été décidé de développer la gestion des referrals en lieu et place des habilitations. C’est pourquoi nous avons désactivé certaines parties du programme en les mettant en commentaires et qui sont relatives à la gestion des habilitations.

Les besoins que nous avons identifiés étaient :

Nécessité pour le thread principal de l’application de faire toutes les initialisations nécessaires au

bon démarrage du logiciel. Prévoir un module chargé de la configuration du proxy, soit par ligne de commande (et son

interprétation) soit par fichier de configuration (et sa lecture et son interprétation). Il nous a semblé bon que ce module puisse générer automatiquement un fichier de configuration «type » au cas où celui-ci ne soit pas trouvé. Nécessité d’un module qui permette d’assurer l’interface console avec l’opérateur du proxy, ne serait-ce que pour arrêter le proxy proprement et passer quelques ordres de type statistique.

Nécessité de traiter les différentes transactions des clients en parallèle et prévoir un algorithme adapté de traitement des différents messages entre le proxy, le client et le serveur LDAP. Pour cela, le module de traitement d’un client doit pouvoir communiquer avec l’annuaire à tout moment. Il ne faut pas que l’envoi d’un message à un client soit bloqué par le traitement des messages d’un autre client.

proxy. Ainsi, on pourra fixer une limite dans le fichier de configuration. Si un client cherche à accéder au proxy à un moment où le nombre maximal est déjà atteint, il se verra rejeter sa connexion. Il faudra qu’il essaye plus tard. Nécessité d’avoir un module qui soit chargé d’accepter les demandes de connexions des nouveaux clients (et de faire du filtrage si nécessaire). L’acceptation d’une demande de connexion par le proxy doit pouvoir se faire en parallèle du traitement des clients déjà en cours de traitement et du traitement des ordres passés à la console par l’opérateur.

Il nous a semblé intéressant de limiter le nombre de threads qui soient simultanément dans le

Une fois ces modules bien identifiés, nous avons rédigé un document « Spécifications Fonctionnelles » qui les regroupait. On trouvera dans la partie VI.C la description de la façon dont nous avons architecturé finalement ces fonctionnalités.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 21
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 21
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 21

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:21/46

2. Etude des librairies fournies par OpenLDAP

Nous nous sommes basés sur le package OpenLDAP 1.2.7 datant de février 2000 pour réaliser notre proxy. Ce package est dérivé de la version 3.3 Release de l’Université 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 d’aide Unix (man).

Des librairies et leurs fichiers source : libavl, liblber, libldap, libldbm, libldif, liblthread, liblutil

Des serveurs et leurs fichiers sources : ldapd (démon LDAP), slapd (serveur d’annuaire), slurpd

(outil de réplication entre annuaires). Tous les outils nécessaires à 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 d’information que nous avions à disposition pour utiliser ces librairies sont les fichiers man décrivant les primitives des fichiers encode.c et decode.c ainsi que les sources des serveurs et clients présentés ci dessus. Notre premier programme avait pour but de récupérer une requête LDAP émise par un client JNDI (que nous avions développé plus tôt quand nous découvrions cette API Java). OpendLDAP utilise les structures de données suivantes :

Un BerElement est une suite d’octets codés sous forme hexadécimale. Les messages LDAP sont stockés sous cette forme par l’API OpenLDAP. Un SockBuf est une structure dans laquelle peuvent être stockés plusieurs message LDAP (sous forme de BerElement). Les primitives que nous avions à disposition étaient alors :

ber_get_next pour récupérer 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 ) d’un message LDAP. Ces primitives sont de très bas niveau et nécessitent une connaissance parfaite du codage BER des éléments de la grammaire LDAP, connaissance que nous ne pouvions pas avoir, faute de données suffisantes. Après une lecture plus approfondie des sources des serveurs et clients nous avons remarqué que l’utilisation d’une primitive de plus haut niveau (ber_scanf ) pourrait rendre le codage plus simple et plus rapide.

L’interface fournie par OpenLDAP que nous allions utiliser étant alors de très bas niveau (codage/décodage BER des messages LDAP) il nous a fallu développer une interface de niveau supérieur qui pourrait être intégrée dans le Proxy. Cette nouvelle interface cachera aux couches supérieures le codage/décodage des messages LDAP et ceux-ci seront stockés sous forme d’objets C++, l’utilisation en sera plus simple.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 22
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 22
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 22

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:22/46

B. Développement d’une interface LDAP

L’API OpenLDAP nous fournissant des primitives de trop bas niveau (codage et décodage BER), il a été nécessaire de développer une couche LDAP de niveau supérieur qui permette de manipuler des messages LDAP de façon plus simple.

1. Structures de données

Pour une utilisation plus simple des données, nous avons décidé de stocker les informations contenues dans les messages sous forme d’objet C++. Chaque élément du protocole LDAP défini dans la grammaire ASN1 (cf. Annexe A ) est donc un objet C++. Par exemple, l’élément LDAPResult est un objet LDAPResult contenant les variables :

ResultCode : un entier. MatchedDN : un pointeur vers un caractère. ErrorMessage : un pointeur vers un caractère. Referral : un pointeur vers un objet Referral. Un message LDAP est un objet LDAPMess contenant alors toutes les informations nécessaires à la compréhension et à la reconstruction du message.

L’objet que manipuleront les couches supérieures à cette interface est l’objet LDAPConnexion, qui encapsule un objet LDAPMess et une connexion vers un serveur ou un client. Les méthodes de cette classe sont :

SendLDAP : pour envoyer un message LDAP, stocké sous forme d’objet LDAPMess, sur une socket donnée en paramètre.

RecvLDAP : pour recevoir d’une socket donnée en paramètre, un message qui sera stocké sous

forme d’objet LDAPMess. ImportLDAP : pour «importer » un objet LDAPMess d’un objet LDAPConnexion à un autre.

2.

Choix d’architecture

Il existe un fichier source (de bind.cpp à extended.cpp )pour chaque catégorie de verbes LDAP, un ficher source (ldapv3.cpp ) pour l’ensemble des éléments de la grammaire LDAPv3 autres que les verbes ainsi qu’un fichier source concernant les exceptions (cf. ci-dessous). La relecture et la modification sont alors facilitées, le code étant plus clair.

3. Choix de conception

Les méthodes de classes

L’ensemble des objets de la grammaire LDAPv3 possède les quatre même méthodes :

ÿ Un constructeur, prenant un BerElement en argument ( pour recevoir un message).

ÿ Un destructeur.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 23
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 23
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 23

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:23/46

ÿ Une méthode print pour l’affichage des messages LDAP.

ÿ Une méthode permettant de construire un BerElement (pour envoyer un message).

Ainsi, la classe BindRequest contient les méthodes suivantes :

ÿ Le constructeur BindRequest (BerElement *ber)

ÿ Le destructeur ~BindRequest

ÿ La méthode print(int incr) (l’argument incr permet l’indentation pendant l’affichage).

ÿ La méthode BuildBindRequest(BerElement *ber) qui retourne un BerElement.

Les exceptions Il se peut que le client émette des messages erronés, ne respectant pas le protocole. Dans ce cas, les messages reçus ne peuvent être lus correctement. Quand un tel cas se présente, une exception est levée. Elle doit être récupérée par les couches supérieures pour être traitée. Le traitement dépend de la gravité de l’erreur. Si le Proxy a pu lire le verbe LDAP de la requête du client, il retourne au client un message lui signalant que sa dernière requête ne respecte pas le protocole, sinon, il doit fermer la connexion. Des exceptions de deux types peuvent alors être levées suivant la conduite à tenir.

LDAPConnexion et LDAPMess Les objets LDAPConnexion et LDAPMess ont été développés de telle sorte qu’une réutilisation de cette interface soit possible pour le développement d’une application autre qu’un 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ù l’ouverture d’une nouvelle connexion, vers un annuaire référé (cf. VI.E Gestion de la résolution des referrals) par exemple, est nécessaire, il suffit de créer un nouvel objet LDAPConnexion en appelant le constructeur avec la nouvelle socket en paramètre. Les objets LDAPConnexion sont donc indépendants les uns des autres. La primitive importLDAP permet l’échange d’informations entre deux connexions.

importLDAP permet l’échange d’informations entre deux connexions. Schéma de fonctionnement de l’interface LDAP

Schéma de fonctionnement de l’interface LDAP

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 24
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 24
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 24

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:24/46

C. Architecture globale du proxy

Suite aux besoins qui ont été exprimés (cf. la partie VI.A.1), voici comment nous avons conçu notre proxy LDAP :

Ci dessous un schéma de l’architecture globale du logiciel.

dessous un schéma de l’architecture globale du logiciel. Le Proxy a été développé comme une application

Le Proxy a été développé comme une application Win32 avec utilisation de la console (fenêtre DOS). Le proxy est démarré par un opérateur en tapant au clavier dans une fenêtre DOS le nom du programme. Aucun paramètre de démarrage n’est requis, toute la configuration du proxy est lue à partir d’un fichier texte de configuration. Cette configuration, ainsi que d’autres informations sont rangées en mémoire globale partagée (heap), accessible par tous les threads.

Une fois le proxy démarré et le thread gestionnaire de connexions lancé, le thread principal joue le rôle d’interface avec l’administrateur du proxy, notamment pour permettre l’arrêt du proxy. Il permet aussi d’afficher des informations concernant le fonctionnement courant du proxy et des statistiques. Le module principal du proxy est constitué d’une collection de fonction C dont la fonction «main » s’exécutant au sein du principal thread de l’application. Les principales responsabilités de ce module sont :

Chargement de la configuration de démarrage

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 25
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 25
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 25

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:25/46

Création des structures de données globales et partagées

Démarrage du thread gestionnaire de connexions pour les clients

Gestion d’une interface console avec l’opérateur du proxy

Arrêt final du proxy

Le proxy LDAP tel que nous l’avons conçu est configurable par l’intermédiaire d’un fichier de configuration. Ce fichier est au format texte et doit se trouver dans le répertoire de travail (le même repertoire que l’exécutable ou dans le PATH). Si le proxy ne trouve pas le fichier de configuration, le proxy génère automatiquement dans le repertoire courant un fichier de configuration type. Il n’y aura plus qu’à adapter ce fichier pour ses besoins. L’option «fichier de configuration » a été préférée à l’option «ligne de commande » en raison du nombre de paramètres nécessaires.

Le thread gestionnaire de connexions a pour rôle d’attendre l’arrivée de nouvelles connexions de clients, de les accepter et de démarrer un thread qui traitera leurs requêtes. Il utilise pour cela une socket en mode serveur et crée des sockets clientes attribuées aux clients. Cette socket cliente est passée en paramètre au thread chargé du client qui crée une socket de connexion à l’annuaire. Chacun des threads-clients possède donc au moins deux sockets de connexion : une vers le client et une autre vers l’annuaire. Une autre socket de connexion vers un autre annuaire pourra éventuellement être ouverte en cas de dé-référencement d’un «referral ». Le module gestionnaire de connexions est conçu de façon très simple sous forme d’une classe. Le module principal du proxy instancie une fois et une seule en créant un objet de la classe «HandlerCx ».

Ci dessous un diagramme de séquence représentant un cas de fonctionnement courant du proxy, en liaison avec le client et l’annuaire

diagramme de séquence représentant un cas de fonctionnement courant du proxy, en liaison avec le client
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 26
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 26
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 26

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:26/46

Nous avons éprouvé la nécessité de conserver en mémoire un certain nombre d’informations concernant les clients dont les requêtes sont en train d’être traitées. Pour cela, nous avons défini une classe «ClientPool » comme variable globale et qui permet de stocker toutes les informations relatives aux différents clients qui s’exécutent au sein du proxy. Cet objet est donc une base de connaissance des clients en cours de traitement. La taille de l’ensemble associé est égale au paramètre de configuration permettant de contrôler (limiter) le nombre maximum de threads de clients présents à un instant donné dans le proxy. Cette fonctionnalité permet d’éviter de faire saturer le serveur hébergeant 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 éléments de cet ensemble sont des objets de classe «ClientInfo » et qui regroupent des informations variées : un handle de thread permettant de contrôler le thread du client, un pointeur vers l’objet 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 supportée par le client. On y mémorise aussi le message de début de connexion et qui permet d’identifier le client. On peut ainsi mémoriser ce dont on a besoin pour arrêter un thread, fermer son handle (noyau NT) et détruire l’objet client, fermer les sockets ouvertes Cette structure est globale et partagée : elle est créée par le thread principal, remplie par le thread gestionnaire de connexions, et vidée lorsqu’un thread se termine de façon naturelle ou à l’arrêt du proxy. Cette structure est protégée contre les accès concurrents des différents threads par un mutex (mutual exclusion). En effet, lors de la connexion d’un client, un objet de classe ClientInfo est créé et ses variables sont affectées. Mais durant cette phase de création du client, la structure clientpool se trouve momentanément dans un état instable. La partie de code concernée constitue une section critique. Si cette partie de code n’était pas protégée par un mutex, une erreur pourrait survenir si un autre thread faisait un parcours de la structure clientpool (par l’appel à une méthode print, rechercher ou ajouter). La réalisation de cette exclusion mutuelle fait appel à un objet système de l’API Win32 :

l’objet mutex.

D. Algorithme de traitement des messages

Comme c’est expliqué dans la RFC 2251 (définition du protocole LDAPv3), les échanges de

messages LDAP entre un client et un annuaire ne sont pas synchrones. Il faut bien comprendre que l’algorithme naïf de proxy LDAP suivant est faux :

Attendre une requête du client

L’envoyer à l’annuaire

Attendre le(s) résultat(s) de l’annuaire

Transmettre le(s) résultat(s) au client

Recommencer

Un client peut à tout moment décider par exemple d’envoyer un message «abandon » à l’annuaire et un annuaire peut à tout moment envoyer des messages «non sollicités » au client. Nous avons donc développé un algorithme asynchrone utilisant l’instruction «select() » liée aux communications par socket permettant de déterminer si des données sont arrivées sur une connexion socket. L’instruction

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 27
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 27
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 27

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:27/46

select permet de détecter (durant une période de temps donnée limitée par un délai «timeout ») un événement se produisant sur un ensemble de sockets. Cet événement peut être :

La socket devient prête en lecture (des données sont arrivées)

La socket devient prête en écriture

La socket est en erreur

Nous détectons ainsi l’arrivée d’un message sur une connexion : le traitement consiste le plus souvent à l’envoyer à l’autre connexion. On échange ainsi les messages arrivant entre le client, le proxy et l’annuaire.

Ci dessous un diagramme de séquence représentant un cas de fonctionnement standard lors d’une transaction avec un seul client LDAP

standard lors d’une transaction avec un seul client LDAP On voit sur ce diagramme différents types

On voit sur ce diagramme différents types de messages (ou verbes) faisant partie de la grammaire LDAP. Comme dit précédemment, le client peut envoyer un message «AbandonRequest » à tout moment et la détection d’arrivée de données sur un port de communication prend tout son sens.

E. Gestion de la résolution des referrals

Comme nous l’avons expliqué, un referral est un type de message LDAPv3 qui peut être retourné au client par l’annuaire si celui-ci n’a pas la connaissance des données recherchées. Inclure dans notre proxy un module de traitement des referrals constitue une vraie valeur ajoutée.

Lors de la réception d’un referral par le proxy, plusieurs choix s’offrent à nous. Il s’agit ici d’une politique de gestion des referrals. Une variable de notre fichier de configuration permet de fixer la façon dont les referrals seront traités par le proxy.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 28
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 28
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 28

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:28/46

pas

transmis au client (il est passé

DROP :

le

referral

n’est

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

données

manquantes

et

retourner le résultat au client.

: le proxy suit le referral pour trouver les données manquantes et retourner le résultat au
: le proxy suit le referral pour trouver les données manquantes et retourner le résultat au
: le proxy suit le referral pour trouver les données manquantes et retourner le résultat au
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 29
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 29
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 29

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:29/46

MULTICASTING(non

implémenté) :

le

proxy

contacte tous

les

annuaires

connus

pour

trouver

les

données

manquantes. Le

contact de tous ces annuaires doit se faire en parallèle et le premier annuaire à répondre correctement (avec les données recherchées) est celui dont les résultats sont transmis au client

est celui dont les résultats sont transmis au client Ces quatre règles sont prévues par la

Ces quatre règles sont prévues par la norme X500 (normalisations 88 et 93) et sont détaillées à l’url suivante : http://www.spidernet.tm.fr/

Ci dessous un diagramme de séquence représentant un cas de fonctionnement standard lors du traitement de type CHAINING d’un referral

diagramme de séquence représentant un cas de fonctionnement standard lors du traitement de type CHAINING d’un
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 30
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 30
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 30

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:30/46

La résolution des referrals que nous avons implémentée est complète car nous pouvons résoudre tous les referrals contenus dans un message LDAP et nous pouvons aussi résoudre une succession de referrals envoyés dans des messages LDAP séparés. De plus, notre algorithme permet de résoudre des referrals successifs, dans le cas où l’information référée contient elle-même des referrals. La profondeur de résolution de referrals ainsi chaînés est de plus paramétrable.

Les résultats ainsi retournés au clients sont complets et tout se passe de façon transparente pour lui. Notre proxy simule ainsi pour le client la présence d’un annuaire LDAP qui contienne l’ensemble des informations recherchées. L’objectif de consolidation est atteint.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 31
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 31
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 31

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:31/46

VII. Tests et validation

A. Tests et validation

Les différents tests effectués ont été :

1. Les tests de conformité

Il a fallu couvrir de façon exhaustive tous les éléments de la grammaire LDAP (v2 et v3).

¸ Ces tests ont été principalement effectués à l’aide du Navigateur LDAP LDAPBrowser (client en Java)

¸ Nous avons aussi développé une interface html pour tester les filtres. Cette interface fonctionne avec le navigateur Netscape (qui s’appuie sur l’API d’annuaire de Netscape NSDK) qui lit des LDAPURL et affiche le résultat sous forme d’une page web. Nous avons ainsi pu tester tous les types de filtres lors d’une requête ldapsearch.

¸ Nous avons utilisé DirectoryMark pour tester les différents éléments de la grammaire LDAP. Ce programme permet de tester les annuaires en leur envoyant de nombreuses requêtes et ainsi de générer un rapport de performance de l’annuaire.

Parmi les éléments de la grammaire LDAPv3, les verbes ExtendedRequest et ExtendedResponse ainsi que l’élément ExtensibleMatch n’ont pas été testés faute de clients les traitant.

Les tests que nous avons effectués l’ont été en utilisant principalement l’annuaire Netscape Directory Server 4.1. Nous avons aussi fait quelques tests beaucoup plus sommaires en utilisant le Global Directory Server 3.0 d’Isocor. Un bug a été constaté concernant l’utilisation conjointe du GDS v2.1 et v3.0, du proxy et de requêtes contenant des contrôles optionnels. Ce bug est détaillé à la section Améliorations et Bugs.

2. Les tests de stress

L’accès au Proxy par un nombre élevé de clients et l’envoi d’un nombre élevé de requêtes clientes ont été simulés et observés. La plupart des pertes en temps créées par le Proxy sont dues à la gestion des sockets. De tels tests permettent d’observer 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 très court. Une socket serveur traite les demandes de connexion une par une et stocke les demandes en attente dans une file d’attente. Celle-ci étant de taille limitée, il se peut qu’un client ne puisse pas se mettre en attente. Il se passe alors ce que l’on 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 rejetée si l’on atteint le nombre maximum de threads dans le proxy.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 32
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 32
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 32

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:32/46

Ces tests ont été réalisés :

¸ En utilisant DirectoryMark : il permet de simuler un grand nombre de requêtes provenant de clients. Pour créer un script contenant de nombreuses requêtes on utilise un script perl qui génère un fichier de test concernant 1000 entrées. Ces scripts ont permis de tester de nombreuses requêtes de types différent. Le proxy a bien réagi à ces tests de stress, nous n’avons pas remarqué de ralentissement spécial ni de goulet d’étranglement.

¸ 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. L’import de ce fichier ldif génère un grand nombre de requêtes de type ldap_add.

3. Les tests d’endurance

Nous avons testé notre proxy dans son fonctionnement courant en essayant de détecter une augmentation éventuelle des ressources utilisées. Les outils utilisés sont l’Analyseur de performance Windows ainsi que Purify (Rational Corporation).

¸ L’interface LDAP (telle qu’elle a été conçue) et les librairies qu’elle inclue gèrent correctement la mémoire. Toute la mémoire allouée est relâchée.

¸ L’augmentation des ressources mémoire a été observée lorsque plusieurs threads client sont créés. Malgré l’utilisation de Purify, nous n’avons pas pu corriger ces problèmes de fuites de mémoire. Nous savons que les threads de la librairie Win32 ne libèrent pas toutes leurs ressources en fin de vie.

4. Les tests de robustesse

Ce sont les tests de résistance du Proxy aux cas d’utilisation inhabituels.

¸ Un client peut envoyer des requêtes erronées. Dans ce cas, le Proxy retourne au client un message LDAP lui signalant l’erreur : erreur de protocole (ResultCode 2).

¸ Le fichier de configuration peut contenir des erreurs. Celles ci peuvent boguer le Proxy à l’exécution (variables non initialisées, mauvais type de variable). Nous avons développé un module de vérification du fichier de config : toute variable de configuration non initialisée ou erronée est détectée et signalée et le proxy refuse de démarrer.

5. Les tests de choix de liaison (gestion des referrals)

La réaction du proxy aux types de liaisons possibles a été testée :

Comportement gênant :

Si la sortie du proxy est malencontreusement dirigée vers son entrée, à la connexion d’un client, le proxy va lancer autant de threads qu’il peut (jusqu’à la limite définie dans le fichier de configuration). Le dernier de ces threads ne pourra pas contacter l’annuaire (le proxy refusera de lancer un nouveau thread) et les différents threads lancés se fermeront les uns à la suite des autres. La connexion avec le client sera finalement fermée. Même comportement au client suivant. Ce comportement n’entraîne pas de bug du proxy mais empêche les clients d’accéder au service (Denial Of Service). Nous ne détectons pas ce cas d’utilisation ni n’avertissons l’opérateur du proxy.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 33
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 33
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 33

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:33/46

Comportement dangereux :

Ce cas d’utilisation est dangereux si on ne fixe pas de limite au nombre de threads pouvant être démarrés.

Solution :

On pourrait détecter ce cas d’utilisation en effectuant une résolution DNS des deux couples (proxy.ipaddress, proxy.port) et (dsa.ipaddress, dsa.port) et en comparant les résultats. Mais cette vérification est trop simple si l’on envisage le cas de deux proxy qui se désignent mutuellement comme étant le serveur d’annuaire.

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 n’avons pas pu entièrement le tester. Nos tests se sont limités à une seule url retournée par message LDAP et nous n’avons pas pu dépasser une profondeur de 3 en résolution ( 3 referrals successifs). Politique MULTICASTING : Non encore développée.

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 l’annuaire seul. L’outil (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 l’annuaire seul et l’annuaire en passant par le proxy pendant 10 minutes environ (à quelques secondes près).

Nous avons effectué nos tests sur l’architecture réseau décrite ci-dessous :

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 34
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 34
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 34

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:34/46

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

Principe des tests de performance avec DirectoryMark :

DirectoryMark s’exécute dans un processus client au sein duquel plusieurs threads peuvent envoyer des requêtes. Chaque thread envoie plusieurs dizaines de fois la même requête au proxy (ou directement à l’annuaire) et ceci pendant au moins X minutes (X est un nombre qui est paramétrable dans le fichier de config de DirectoryMark). Au bout de ces X minutes, DirectoryMark s’arrête et fourni le bilan de ce qui s’est passé et notamment le nombre de requêtes qui ont pu être envoyées. Le rapport « nombre_de_requêtes_traitées / X » nous donne donc le débit. DirectoryMark nous donne aussi d’autres informations utiles : délais de latences, type des transactions

Tests en réseau local :

Ces tests ont été effectués entre nos deux machines de développement (schmitt et robine) Résultats avec un seul thread :

¸ 1537 requêtes «search » adressées directement à l’annuaire

En passant par le proxy : il a pu en traiter 1522 soit une perte de performance de 1%.

¸ 53186 requêtes «search, add, delete et modify » adressées directement à l’annuaire En passant par le proxy : il a pu en traiter 50440 soit une perte de performance de 5%.

Résultats avec 15 threads :

¸ 1200 requêtes «search » adressées directement à l’annuaire, En passant par le proxy : il a pu en traiter 1192 soit une perte de performance de 0.6%.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 35
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 35
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 35

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:35/46

Les opérations effectuées pour les tests ci dessus sont souvent des opérations LDAPsearch lourdes par rapport aux faibles capacités de nos machines : la charge de travail de l’annuaire pour répondre à chaque requête est importante, ce qui explique que seulement 2,4 opérations sont effectuées 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. C’est pourquoi nous avons effectué d’autres tests pour lesquels l’annuaire est hébergé par un serveur très performant.

Tests sur une plate-forme plus performante :

Ces tests ont été effectués entre les machines DGA_SERV et Aladin4. Nous avons effectué 4 fois le même test. Le résultat présenté ci dessous en est la moyenne. Résultat avec 5 processus de 10 threads chacun soit 50 clients simultanés pendant 10 minutes :

¸ 200926 requêtes «search » adressées directement à l’annuaire En passant par le proxy : il a pu en traiter 140836 soit une perte de performance de 30%. Cette perte de performance peut venir du réseau, des temps de latence dus à l’ouverture de socket ou enfin d’une latence due au proxy lui-même (le plus probable). Nous avons observé des latences (délai entre l’émission de la requête par le client et la réception des résultats par le client) comprises entre 111 ms et 3114 ms. Les latences constatées en s’adressant directement à l’annuaire sont comprises entre 6 ms et 2911 ms.

Nous sommes très conscients de la difficulté d’interprétation de ces tests. En effet, ils dépendent pour beaucoup de l’environnement technique utilisé :

La machine hébergeant le proxy est-elle puissante, a-t-elle plusieurs processeurs ?

Quelle est la rapidité des connexions réseaux ?

Qu’utilise t-on comme annuaire ? Est-ce un annuaire LDAP ou un serveur LDAP qui traduise les

requêtes en DAP de façon interne ? Quelle est la performance de la machine qui héberge le serveur d’annuaire ?

Quels sont les clients LDAP utilisés ? En quel nombre, et d’où viennent les connexions du réseau ?

En raison de toutes ces difficultés d’interprétation, on ne prendra les valeurs données précédemment et notamment les pertes de performance (de 1% dans le cas le plus favorable à 30% dans le cas le plus défavorable) que de façon indicative. Une campagne de tests planifiée et pensée de façon exhaustive et rigoureuse étant nécessaire pour correctement évaluer notre logiciel.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 36
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 36
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 36

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:36/46

VIII. Améliorations et Bogues

A. Améliorations possibles

Voici des améliorations qu’il serait sans doute utile d’apporter à 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 intéressant de développer une macro qui permette de regrouper tous les messages dans un seul fichier et qui affiche le bon message suivant la langue préférée.

Verrouillage de la console pour accès 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 parallèle. Les messages se trouvent donc mélangés à l’écran, un caractère sur deux par exemple. On pourrait inclure dans la macro la prise et la libération d’un objet mutex qui permettrait ainsi d’accéder à 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 l’affichage pour tous les messages le numéro du thread client qui est concerné (variable client_id de l’objet handlerclient). De façon plus générale, réfléchir à séparer les différentes traces des threads client.

Cache de correspondances DN -> @IP pour traitement rapide des referrals On pourrait mémoriser au sein du proxy une table cache de traduction DN vers adresse IP. Cette table contiendra au bout d’un certain nombre de requêtes, pour chaque requête qui a eu pour conséquence la réception d’un referral, le DN (Distinguished Name) de l’entrée recherchée et l’adresse de l’annuaire référé qui connaît les informations recherchées. Cette table permettra notamment d’éviter de contacter des annuaires intermédiaires (avec à chaque fois une ouverture de sockets, une requête LDAP et le traitement du résultat) pour finalement contacter le bon annuaire.

Implémentation du système d’habilitations :

Comme nous l’avions commencé, nous pourrions implémenter un système de vérification des droits des utilisateurs au niveau du proxy en s’appuyant pour cela sur les habilitations telles qu’elles ont été définies dans WebD&CA.

Ajout d’un module de statistiques Ajout d’une action exécutable par l’opérateur du proxy qui puisse lui donner des informations complémentaires sur le fonctionnement du proxy : délais, débits, nombre de clients, nombre moyen de requêtes, types des requêtes (verbes ldapv3) les plus utilisés, horaires de pointes

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 37
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 37
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 37

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:37/46

Permettre l’accès à plusieurs annuaires Actuellement, on donne dans le fichier de configuration l’adresse (adresse IP et port TCP) de l’annuaire à contacter pour résoudre les requêtes des clients. Peut-être serait-il bon de laisser la possibilité de contacter plusieurs annuaires pour le cas d’annuaires répliqués et pour lesquels il faudrait faire de l’équilibrage de charge par exemple.

Ne pas décoder les messages LDAP Actuellement, chaque message LDAP reçu par le proxy est complètement décodé par notre module LDAP (s’appuyant sur le module BER). Les messages sont ensuite traités par l’algorithme de proxy et ré-encodés avant d’être envoyés au destinataire. Toutes ces étapes prennent du temps. Il serait peut-être bon de laisser la possibilité de ne pas décoder et ré encoder les messages afin d’accélérer le fonctionnement du Proxy. Il se contenterait alors de recevoir sur une socket et de renvoyer exactement le mêmes données sur une autre socket. Néanmoins, cette idée nécessite de complètement court-circuiter notre API LDAP et l’API Ber de OpenLDAP. En effet, la routine ber_get_next() qui récupère 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 début du berelement (elle enlève certains tags) et le message ldap n’est plus récupérable autrement que par un décodage complet. Ainsi, il faudrait seulement lire sur la socket le message, le placer dans un buffer temporaire et l’envoyer au destinataire (l’autre 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 repérer le message bind ni les referrals.

B.

Bogues et restrictions

Fuites de mémoires Nous avons pu observer des fuites de mémoire lors du deboguage du proxy sous Windows NT. Pour cela, on pourra modifier le proxy pour utiliser les primitives de gestion de thread de l’API C comme _beginthread() au lieu des primitives de l’API Win32 comme CreateThread().

Encodage du champ «Controls » Lors des tests du proxy avec un serveur d’annuaire GDS d’ISOCOR, nous avons remarqué que le codage du champ « Controls » d’une requête LDAP du client ne respecte pas le protocole LDAPv3 d’après le serveur. Pour contourner ce bug, que nous n’avons pas eu le temps de corriger, nous avons «désactivé » l’encodage du champ «controls » dans le proxy. Ce champ est utilisé pour étendre l’utilisation des messages LDAP. Dans un cas d’utilisation normale, le fait de désactiver ces champs n’a pas d’incidence pour le client ou le serveur.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 38
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 38
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 38

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:38/46

IX.

Planning

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 38 /
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 39
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 39
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 39

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:39/46

X.Conclusion

Nous tirons globalement de ce stage un bilan très positif, bien que nous ayons eu à faire face à des difficultés. Notre capacité à les résoudre et les méthodologies que nous avons employées pour les résoudre finalement sont des motifs de satisfaction.

L’événement 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 collègues.

Nous avons eu un certain nombre de difficultés techniques. Notamment la difficulté de compréhension des librairies d’OpenLDAP qui sont mal commentées et peu documentées. Nous avons aussi eu à résoudre des bogues dans notre application et à mettre en œuvre le déboguage d’une application multithread avec tous les problèmes de concurrence d’accès et de synchronisation que cela suppose. Nous n’avons pas pu trouver de client LDAP qui permette de tester toute la grammaire LDAP de façon aisée.

Mais ce stage a été pour nous le plaisir et l’occasion de découvrir les technologies d’annuaires LDAP, qui nous étaient au départ complètement inconnues. Il nous a apporté la satisfaction de travailler sur un projet de Recherche et Développement puisque la réalisation de ce logiciel constitue pour le Département e-Solutions un produit qui pourra s’intégrer dans le futur au sein de plusieurs offres pour les clients de Bull.

Nous avons atteint notre objectif de réalisation d’un proxy d’annuaire LDAP multi-threadé, ne dépendant pas de librairies commerciales, et qui est capable de résoudre des referrals. D’autre part, il est modulaire et les fichiers sources du projet sont entièrement accessibles si bien que Bull e- Solutions pourra, par des développements ultérieurs, y ajouter les fonctionnalités souhaitées par ses clients.

Ce projet a été l’occasion de mettre en pratique la formation théorique que nous avons reçue à l’ENSIMAG, qui s’est révélée adaptée aux compétences souhaitées.

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 40
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 40
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 40

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:40/46

Livres :

XI.

Bibliographie

“Implementing LDAP”, Wrox press limited 1999 “Developper sous windows 95 et NT4.0”, Microsoft Press

Internet :

JNDI

www.java.sun.com/products/jndi

Snacc4Java

www.alphaworks.ibm.com/tech/snaccforjava

OSS Nokalva

www.oss.com/news/press060399.html

Michigan University OpenLDAP

www.umich.edu/~dirsvcs/ www.openldap.org

LDAP v2

www.ietf.org/rfc/rfc1777.txt

LDAP v3

www.ietf.org/rfc/rfc2251.txt

Netscape SDK

developer.netscape.com/software/sdks/index.html

Serveur de Clayton Donley

www.linc-dev.com/

Les outils Cup/Jlex

http://www.cs.princeton.edu/~appel/modern/java/CUP/

Proxy Innosoft descript.html Proxy MaXware Proxy Nexor Directory Boundary Agent BullSoft Netwall 4.0 Une documentation X500 DirectoryMark

http://www.cs.princeton.edu/~appel/modern/java/JLex/

http://www.innosoft.com/directory_solutions/ilps-

http://www.maxware.no/mias/

http://www.nexor.com/products/dba.htm

http://www.securware.com/netwall/

http://www.spidernet.tm.fr/

www.mindcraft.com

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 41
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 41
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 41

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:41/46

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

modDNResponse

compareRequest CompareRequest, compareResponse CompareResponse,

ModifyDNRequest,

ModifyDNResponse,

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

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 42
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 42
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 42

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:42/46

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 strongAuthRequired -- 9 reserved --

referral

adminLimitExceeded

(7),

(8),

(10), -- new (11), -- new

unavailableCriticalExtension (12), -- new

confidentialityRequired saslBindInProgress noSuchAttribute undefinedAttributeType inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --

inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --
inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --
inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --
inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --
inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --
inappropriateMatching constraintViolation attributeOrValueExists invalidAttributeSyntax -- 22-31 unused --

(13), -- new (14), -- new

(16),

(17),

(18),

(19),

(20),

(21),

noSuchObject

(32),

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 43
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 43
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 43

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:43/46

aliasProblem

invalidDNSyntax (34), -- 35 reserved for undefined isLeaf --

aliasDereferencingProblem -- 37-47 unused --

inappropriateAuthentication (48),

(33),

(36),

invalidCredentials

(49),

insufficientAccessRights

(50),

busy

(51),

unavailable

(52),

unwillingToPerform

(53),

loopDetect

(54),

-- 55-63 unused -- namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists

-- 55-63 unused -- namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists
-- 55-63 unused -- namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists
-- 55-63 unused -- namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists
-- 55-63 unused -- namingViolation objectClassViolation notAllowedOnNonLeaf notAllowedOnRDN entryAlreadyExists

(64),

(65),

(66),

(67),

(68),

objectClassModsProhibited

(69),

-- 70 reserved for CLDAP --

affectsMultipleDSAs -- 72-79 unused --

other

-- 81-90 reserved for APIs --

(71), -- new

(80) },

matchedDN

errorMessage

referral

LDAPDN, LDAPString, [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,

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 44
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 44
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 44

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:44/46

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

derefAlways

(2),

(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

substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion,

present

approxMatch

extensibleMatch [9] MatchingRuleAssertion }

[3] AttributeValueAssertion,

[7] AttributeDescription, [8] AttributeValueAssertion,

SubstringFilter ::= SEQUENCE {

type

-- at least one must be present

substrings

AttributeDescription,

SEQUENCE OF CHOICE {

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 45
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 45
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 45

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:45/46

initial [0] LDAPString,

any

final

[1] LDAPString, [2] LDAPString } }

[1] LDAPString, [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 { type AttributeDescription,

vals

SET OF AttributeValue }

SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL

SearchResultDone ::= [APPLICATION 5] LDAPResult

ModifyRequest ::= [APPLICATION 6] SEQUENCE {

object

modification

LDAPDN, SEQUENCE OF SEQUENCE {

operation

ENUMERATED {

add

(0),

modification

delete (1), replace (2) }, AttributeTypeAndValues } }

AttributeTypeAndValues ::= SEQUENCE {

type

AttributeDescription,

vals

SET OF AttributeValue }

ModifyResponse ::= [APPLICATION 7] LDAPResult

AddRequest ::= [APPLICATION 8] SEQUENCE {

entry

LDAPDN,

attributes

AttributeList }

AttributeList ::= SEQUENCE OF SEQUENCE {

type

AttributeDescription,

vals

SET OF AttributeValue }

AddResponse ::= [APPLICATION 9] LDAPResult

Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 46
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 46
Projet de Fin d’études Rapport de soutenance Olivier Schmitt Yannik Soubigou Date: 27/06/00 Page: 46

Projet de Fin d’études Rapport de soutenance

Olivier Schmitt

Yannik Soubigou

Date: 27/06/00

Page:46/46

DelRequest ::= [APPLICATION 10] LDAPDN

DelResponse ::= [APPLICATION 11] LDAPResult

ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {

entry

LDAPDN,

newrdn

deleteoldrdn

newSuperior

RelativeLDAPDN, BOOLEAN,

[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