Serveur HTTP Apache Version 2.4
Description: | Conservation des connexions LDAP et services de mise en cache du résultat à destination des autres modules LDAP |
---|---|
Statut: | Extension |
Identificateur de Module: | ldap_module |
Fichier Source: | util_ldap.c |
Ce module a été conçu dans le but d'améliorer les performances des sites web s'appuyant sur des connexions en arrière-plan vers des serveurs LDAP. Il ajoute aux fonctions fournies par les bibliothèques standards LDAP la conservation des connexions LDAP ainsi qu'un cache LDAP partagé en mémoire.
Pour activer ce module, le support LDAP doit être compilé dans
apr-util. Pour ce faire, on ajoute l'option --with-ldap
au script configure
lorsqu'on construit
Apache.
Le support SSL/TLS est conditionné par le kit de développement LDAP qui a été lié à APR. Au moment où ces lignes sont écrites, APR-util supporte OpenLDAP SDK (version 2.x ou supérieure), Novell LDAP SDK, Mozilla LDAP SDK, le SDK LDAP Solaris natif (basé sur Mozilla) ou le SDK LDAP Microsoft natif. Voir le site web APR pour plus de détails.
Ce qui suit est un exemple de configuration qui utilise
mod_ldap
pour améliorer les performances de
l'authentification HTTP de base fournie par
mod_authnz_ldap
.
# Active la conservation des connexions LDAP et le cache partagé en # mémoire. Active le gestionnaire de statut du cache LDAP. # Nécessite le chargement de mod_ldap et de mod_authnz_ldap. # Remplacez "votre-domaine.example.com" par le nom de votre # domaine. LDAPSharedCacheSize 500000 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 <Location "/ldap-status"> SetHandler ldap-status Require host yourdomain.example.com Satisfy any AuthType Basic AuthName "LDAP Protected" AuthBasicProvider ldap AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one" Require valid-user </Location>
Les connexions LDAP sont conservées de requête en requête. Ceci permet de rester connecté et identifié au serveur LDAP, ce dernier étant ainsi prêt pour la prochaine requête, sans avoir à se déconnecter, reconnecter et réidentifier. Le gain en performances est similaire à celui des connexions persistantes (keepalives) HTTP.
Sur un serveur très sollicité, il est possible que de nombreuses requêtes tentent d'accéder simultanément à la même connexion au serveur LDAP. Lorsqu'une connexion LDAP est utilisée, Apache en crée une deuxième en parallèle à la première, ce qui permet d'éviter que le système de conservation des connexions ne devienne un goulot d'étranglement.
Il n'est pas nécessaire d'activer explicitement la conservation des connexions dans la configuration d'Apache. Tout module utilisant le module ldap pour accéder aux services LDAP partagera le jeu de connexions.
Les connexions LDAP peuvent garder la trace des données
d'identification du client ldap utilisées pour l'identification
auprès du serveur LDAP. Ces données peuvent être fournies aux
serveurs LDAP qui ne permettent pas les connexions anonymes au cours
lors des tentatives de sauts vers des serveurs alternatifs. Pour
contrôler cette fonctionnalité, voir les directives LDAPReferrals
et LDAPReferralHopLimit
. Cette
fonctionnalité est activée par défaut.
Pour améliorer les performances, mod_ldap
met en oeuvre
une stratégie de mise en cache agressive visant à minimiser le nombre de
fois que le serveur LDAP doit être contacté. La mise en cache peut
facilement doubler et même tripler le débit d'Apache lorsqu'il sert des
pages protégées par mod_authnz_ldap
. De plus, le serveur
LDAP verra lui-même sa charge sensiblement diminuée.
mod_ldap
supporte deux types de mise en cache
LDAP : un cache recherche/identification durant la phase
de recherche/identification et deux caches d'opérations
durant la phase de comparaison. Chaque URL LDAP utilisée par le
serveur a son propre jeu d'instances dans ces trois caches.
Les processus de recherche et d'identification sont les opérations LDAP les plus consommatrices en temps, en particulier si l'annuaire est de grande taille. Le cache de recherche/identification met en cache toutes les recherches qui ont abouti à une identification positive. Les résultats négatifs (c'est à dire les recherches sans succès, ou les recherches qui n'ont pas abouti à une identification positive) ne sont pas mis en cache. La raison de cette décision réside dans le fait que les connexions avec des données d'identification invalides ne représentent qu'un faible pourcentage du nombre total de connexions, et ainsi, le fait de ne pas mettre en cache les données d'identification invalides réduira d'autant la taille du cache.
mod_ldap
met en cache le nom d'utilisateur, le
DN extrait, le mot de passe utilisé pour l'identification, ainsi
que l'heure de l'identification. Chaque fois qu'une nouvelle
connexion est initialisée avec le même nom d'utilisateur,
mod_ldap
compare le mot de passe de la nouvelle
connexion avec le mot de passe enregistré dans le cache. Si les
mots de passe correspondent, et si l'entrée du cache n'est pas
trop ancienne, mod_ldap
court-circuite la phase
de recherche/identification.
Le cache de recherche/identification est contrôlé par les
directives LDAPCacheEntries
et LDAPCacheTTL
.