5. Modèle de sécurité
Un annuaire LDAP peut nécessiter une authentification.
L'originalité des serveurs LDAP consiste en ce que l'utilisateur devra
s'authentifier en se présentant comme une entrée de l'annuaire.
Au lieu du traditionnel login utilisé par d'autres types
d'applications, un DN devra être fourni.
L'opération bind est l'opération de
connexion et d'authentification auprès d'un serveur annuaire en
endossant l'identité d'une entrée. Cette opération peut
être simple, auquel cas l'utilisateur doit donner un mot de
passe, ou bien elle peut prendre en paramètre un jeton SASL.
6. Étendre LDAP
Dès la conception du protocole LDAP dans sa version 3,
il a été prévu d'y intégrer la possibilité
d'étendre la norme, soit en modifiant le comportement des
opérations existantes, soit en ajoutant des nouvelles opérations.
Nous allons dans cette section décrire ces deux possibilités.
a. Les contrôles
Les contrôles sont un mécanisme qui permet de
modifier le comportement des opérations standard. Ils sont
envoyés par le client au serveur, en même temps qu'une
requête classique. Ils sont décrits dans le paragraphe 4.1.12 de
la [rfc2251].
Dans une requête, un contrôle est
caractérisé par :
|
Type
|
Il s'agit d'un identifiant du contrôle, sous la forme d'un
OID
|
|
Criticité
|
Un booléen qui indique si le contrôle est critique
ou pas. Si le contrôle est signalé comme étant critique par
le client, le serveur doit absolument exécuter la requête avec le
contrôle associé. S'il ne le peut pas, par exemple parce qu'il
n'implémente pas le contrôle ou parce que le contrôle est
inapproprié avec la requête demandée, il doit retourner
l'erreur unsupportedCriticalExtension et ne pas exécuter la
requête
|
|
Valeur
|
Ce champs est utilisé pour transmettre des valeurs
supplémentaires ; son contenu dépend donc du contrôle
|
Tableau 8: les
contrôles
Les contrôles peuvent être aussi retournés
par un serveur dans une réponse à un client. Ainsi des
interactions sont possibles entre le client et le serveur. Un exemple d'une
telle interaction est le contrôle de recherche paginée,
défini dans la [rfc2696] et supporté par Openldap à partir
de version 2.2.
Ce contrôle permet à un client d'effectuer une
recherche, et de récupérer le résultat de sa recherche par
blocs, au lieu de recevoir toutes les entrées en une seule fois.
Lorsqu'il reçoit une telle requête, le serveur inclus dans sa
réponse le même contrôle, en y incluant un identifiant dans
le champs valeur. Cet identifiant sera ensuite renvoyé par le
client à son tour, afin de demander le bloc suivant.
D'autres contrôles ne nécessitent pas une telle
interaction. C'est le cas du contrôle matchedValuesOnly, dont
l'OID est 1.2.826.0.1.3344810.2.2, et qui est encore à
l'état de draft auprès de l'IETF. Ce contrôle, qui doit
être associé à une recherche, demande à un serveur
de ne retourner, parmi toutes les valeurs des attributs d'une entrée,
que celles qui ont répondu positivement au filtre de la recherche. Ce
contrôle est supporté par Openldap.
| 
